fix(guest): bound thread spawns and reduce stack size in vm-agent#153
fix(guest): bound thread spawns and reduce stack size in vm-agent#153
Conversation
The accept loops in vm-agent spawned unbounded threads with the default 8 MB stack for every incoming vsock connection. Under exec bursts (e.g. Docker health-check storms) this could exhaust guest VM memory. - Reduce per-thread stack to 1 MB via thread::Builder::stack_size - Cap active connection-handling threads at 64 per listener using an Arc<AtomicUsize> semaphore; excess connections are logged and dropped - Separate counters for exec (port 52) and file-I/O (port 53) listeners
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ae59559406
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| handler(conn_fd); | ||
| active_clone.fetch_sub(1, Ordering::Relaxed); |
There was a problem hiding this comment.
Release active slot even if connection handler panics
The active-connection counter is decremented only after handler(conn_fd) returns normally, so any panic inside a handler leaks one slot permanently. This is realistic because the handler path still contains expect/unwrap panics (for example empty start.cmd in handle_piped), and after enough panics the counter reaches 64 and the agent starts dropping all new connections even though no threads are running. Please ensure slot release happens on unwind as well (e.g., guard with Drop or wrap handler execution).
Useful? React with 👍 / 👎.
Summary
MAX_ACTIVE_CONNECTIONS(64) semaphore to cap concurrent connection threadsthread::Builder::stack_sizeTest plan
docker execburst doesn't OOM the guestCloses ABX-238