[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230614165244.59782-1-kuniyu@amazon.com>
Date: Wed, 14 Jun 2023 09:52:44 -0700
From: Kuniyuki Iwashima <kuniyu@...zon.com>
To: <lmb@...valent.com>
CC: <andrii@...nel.org>, <ast@...nel.org>, <bpf@...r.kernel.org>,
<daniel@...earbox.net>, <davem@...emloft.net>, <dsahern@...nel.org>,
<edumazet@...gle.com>, <haoluo@...gle.com>, <hemanthmalla@...il.com>,
<joe@...d.net.nz>, <john.fastabend@...il.com>, <jolsa@...nel.org>,
<kpsingh@...nel.org>, <kuba@...nel.org>, <kuniyu@...zon.com>,
<linux-kernel@...r.kernel.org>, <linux-kselftest@...r.kernel.org>,
<martin.lau@...ux.dev>, <mykolal@...com>, <netdev@...r.kernel.org>,
<pabeni@...hat.com>, <sdf@...gle.com>, <shuah@...nel.org>, <song@...nel.org>,
<willemdebruijn.kernel@...il.com>, <yhs@...com>
Subject: Re: [PATCH bpf-next v2 3/6] net: remove duplicate reuseport_lookup functions
From: Lorenz Bauer <lmb@...valent.com>
Date: Wed, 14 Jun 2023 16:25:05 +0100
> On Tue, Jun 13, 2023 at 7:57 PM Kuniyuki Iwashima <kuniyu@...zon.com> wrote:
> >
> > else {
> > result = sk;
> > }
> >
> > The assignment to result below is buggy. Let's say SO_REUSEPROT group
> > have TCP_CLOSE and TCP_ESTABLISHED sockets.
>
> I'm not very familiar with SO_REUSEPORT, I assumed (incorrectly
> probably) that such a group would only ever have TCP_CLOSE in UDP case
> and TCP_LISTENING in TCP case. Can you explain how I could end up in
> this situation?
When we call conenct() for UDP socket in SO_REUSEPORT group, the state
is changed from TCP_CLOSE to TCP_ESTABLISHED in __ip4_datagram_connect(),
and the socket remains in the group.
That's why we check TCP_ESTABLISHED in reuseport_select_sock_by_hash()
that is always false for TCP but true for UDP in the case above.
Powered by blists - more mailing lists