Messages in this thread | | | Date | Fri, 23 Oct 2020 17:06:28 +0100 | From | Ricardo Dias <> | Subject | Re: [PATCH] tcp: fix race condition when creating child sockets from syncookies |
| |
On Fri, Oct 23, 2020 at 05:56:07PM +0200, Eric Dumazet wrote: > On Fri, Oct 23, 2020 at 5:51 PM Ricardo Dias <rdias@memsql.com> wrote: > > > > On Fri, Oct 23, 2020 at 04:03:27PM +0200, Eric Dumazet wrote: > > > On Fri, Oct 23, 2020 at 1:14 PM Ricardo Dias <rdias@memsql.com> wrote: > > > > > > ... > > > > > > Note that normally, all packets for the same 4-tuple should be handled > > > by the same cpu, > > > so this race is quite unlikely to happen in standard setups. > > > > I was able to write a small client/server program that used the > > loopback interface to create connections, which could hit the race > > condition in 1/200 runs. > > > > The server when accepts a connection sends an 8 byte identifier to > > the client, and then waits for the client to echo the same identifier. > > The client creates hundreds of simultaneous connections to the server, > > and in each connection it sends one byte as soon as the connection is > > established, then reads the 8 byte identifier from the server and sends > > it back to the server. > > > > When we hit the race condition, one of the server connections gets an 8 > > byte identifier different from its own identifier. > > That is on loopback, right ?
Yes it's on loopback.
> > A server under syn flood is usually hit on a physical NIC, and a NIC > will always put all packets of a TCP flow in a single RX queue. > The cpu associated with this single RX queue won't process two packets > in parallel.
And what about the loopback interface? Why couldn't the loopback interface also use a single RX queue?
> > Note this issue is known, someone tried to fix it in the past but the > attempt went nowhere.
| |