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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL+tcoACq7d6ADnDr-Fd_QyBQ=kbC4cjqs1eqLwrcFKHf4ZmHg@mail.gmail.com>
Date: Tue, 20 Aug 2024 00:11:25 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	dsahern@...nel.org, ncardwell@...gle.com, netdev@...r.kernel.org, 
	Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next] tcp: change source port selection at bind() time

On Mon, Aug 19, 2024 at 11:45 PM Eric Dumazet <edumazet@...gle.com> wrote:
>
> On Fri, Aug 16, 2024 at 5:33 PM Jason Xing <kerneljasonxing@...il.com> wrote:
> >
> > From: Jason Xing <kernelxing@...cent.com>
> >
> > This is a follow-up patch to an eariler commit 207184853dbd ("tcp/dccp:
> > change source port selection at connect() time").
> >
> > This patch extends the use of IP_LOCAL_PORT_RANGE option, so that we
> > don't need to iterate every two ports which means only favouring odd
> > number like the old days before 2016, which can be good for some
> > users who want to keep in consistency with IP_LOCAL_PORT_RANGE in
> > connect().
>
> Except that bind() with a port reservation is not as common as a connect().
> This is highly discouraged.
>
> See IP_BIND_ADDRESS_NO_PORT
>
> Can you provide a real use case ?
>
> I really feel like you are trying to push patches 'just because you can'...

You apparently got me wrong and hurt my feelings :/

Since you asked me about this one, I'm going to tell you the whole story.

A few years ago, one of my colleagues reached out to you and
complained about the issue of the new port selection algorithm
(odd/even port selection) to you. But a few years later, the community
finally implemented/extended such IP_LOCAL_PORT_RANGE option to
support finding a suitable port one by one. I'm not sure if you
remembered.

Nearly every month I get issue reports about why the latest kernel
applies a new algorithm because of the high cpu-load increasing so
much suddenly, then I will let them use the older one which I use a
sysctl knob to control internally.

If you pay more attention in these years, you've received more than
one patch trying to use the older algorithm provided for users, even
though they are not accepted. You may ignore the fact. For me, I just
want to provide a way/patch to use the older algorithm for connect()
and bind(), which can be accepted by the community relatively easily.
That's all. I don't believe we are the only special one! So I want to
change something!

Like that 'self-connection' issue, we are also not the only one, so I
exert/push myself to solve the issue thoroughly.

To be honest, whether you accept the patch, I cannot control it, but I
will try my best to do some useful reports and provide real use cases
which are derived from our production.

That's not bad, right?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ