linux-kernel - Re: [PATCH net v3 1/2] net: tcp: lookup the best matched listen socket

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAAVpQUC-bPPar5Q-AoW_sZYrRfLF9Q7Su+163EfmYCBOjqohAA@mail.gmail.com>
Date: Wed, 13 Aug 2025 10:52:41 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Menglong Dong <menglong8.dong@...il.com>
Cc: Jason Xing <kerneljasonxing@...il.com>, edumazet@...gle.com, ncardwell@...gle.com, 
	davem@...emloft.net, dsahern@...nel.org, kuba@...nel.org, pabeni@...hat.com, 
	horms@...nel.org, shuah@...nel.org, kraig@...gle.com, 
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org, 
	linux-kselftest@...r.kernel.org
Subject: Re: [PATCH net v3 1/2] net: tcp: lookup the best matched listen socket

On Wed, Aug 13, 2025 at 5:55 AM Menglong Dong <menglong8.dong@...il.com> wrote:
>
> On Sun, Aug 3, 2025 at 4:32 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > On Sun, Aug 3, 2025 at 12:00 PM Menglong Dong <menglong8.dong@...il.com> wrote:
> > >
> > > On Sun, Aug 3, 2025 at 10:54 AM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > >
> > > > On Sun, Aug 3, 2025 at 9:59 AM Menglong Dong <menglong8.dong@...il.com> wrote:
> > > > >
> > > > > On Sat, Aug 2, 2025 at 9:06 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> > > > > >
> [......]
> > > >
> > > > I'm trying to picture what the usage can be in the userland as you
> > > > pointed out in the MD5 case. As to the client side, it seems weird
> > > > since it cannot detect and know the priority of the other side where a
> > > > few sockets listen on the same address and port.
> > >
> > > For the server side, it needs to add all the clients information
> > > with the TCP_MD5SIG option. For socket1 that binded on the
> > > eth0, it will add all the client addresses that come from eth0 to the
> > > socket1 with TCP_MD5SIG. So the server knows the clients.
> >
> > Right, but I meant the _client_ side doesn't know the details of the
> > other side, that is to say, the server side needs to keep sure the
> > client server easily connects to your preferred listener regardless of
> > what the selection algorithm looks like. In terms of what you
> > depicted, I see your point. One question is if the kernel or API
> > provides any rules and instructions to the users that on the server
> > side the sk1 must be selected in your case? Is it possible for other
> > cases where the sk2 is the preferable/ideal one? I'm not sure if it's
> > worth 'fixing' it in the kernel.
>
> What does sk2 represent here? I don't think that the sk2 should
> be preferable. For now, it is selected by the creating order, and
> there should not be a case that relies on the socket creation
> order......would it?
>
> So the socket should be selected by priority, and sk1, which is binded
> on eth0, has higher priority, which is awarded by the users.
>
> I noticed that the net-next is open, so we can use Kuniyuki's
> solution instead, which is better for the performance ;)

I'll post a series next week when Eric is back.