On Tue, Oct 06, 2026 at 09:56:41PM +0100, Daniel P. Berrangé wrote: > 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.
I tried to find but didn't see an explicit errno for it.. The hope is even if hit it will fail migration with some errno, then a retry would work. It'll be similar to when there's other random network issues when starting migration. > > 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. I expect ports can be scanned, but I didn't expect adhoc connections then drop quickly.. If that exists, it should be able to break incoming side of qemu with current code indeed. AFAIU what we do is we deliver the channel to migration process and then we'll see qemufile IO error.. not too bad since it will very occasionally fail migration, but source unaffected. But I agree, I think we should be more error prone. Looks like TLS is not affected due to the fact that TLS handshake process guaranteed anything forwarded to migration core will be verified and solid. And I believe the migration handshake feature will fix this as a side effect: when we will attach a header to all channels during handshake, then at least randomly connected sockets will fail the check and then we can drop the channel silently until it passes our header check. I'll keep that in mind when working on the feature, which is in near future plan now. > > > 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]> Thanks, -- Peter Xu
