On Tue, Oct 06, 2026 at 02:20:42PM -0400, Peter Xu wrote: > QEMU incoming side may have set a wrong listen() backlog. After the > support of multifd + postcopy now we have four possibilities on setting the > backlog, some of them are wrong: > > Vanilla: 1 (correct) > Multifd: N (wrong, should be N+1) > Preempt: 2 (correct) > Multifd+Preempt: N (wrong, should be N+2) > > No real report for this, found by code observation only. Logically the > backlog (pending accept requests on destination on the listening sockets) > needs to be the maximum of possible channels. Otherwise if the accept > queue full on destination, source QEMU may hit connection errors.
>From a robustness POV, we might also consider retrying connections if we see a transient failure. Though I'm not sure offhand what errrno would result on the client when the accept() queue is full, hopefully there's something distinct. This would mitigate a risk of DoS from an unauthorized client making its own incoming connections concurrently. Such a client is not necessarily malicious, as there are monitoring tools or port scanners that randomly open connections to TCP listener sockets. > Cc: Daniel P. Berrangé <[email protected]> > Fixes: 0705e56496 ("multifd: Use number of channels as listen backlog") > Fixes: e274188612 ("migration: enable multifd and postcopy together") > Signed-off-by: Peter Xu <[email protected]> > --- > migration/socket.c | 25 ++++++++++++++++++------- > 1 file changed, 18 insertions(+), 7 deletions(-) Reviewed-by: Daniel P. Berrangé <[email protected]> With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
