Re: [PATCH net-next v1] tcp/dccp: avoid parity split for socket-local bind range

在 2026/6/30 02:21, Kuniyuki Iwashima 写道:

On Fri, Jun 26, 2026 at 7:00 PM luoxuanqiang [off-list ref] wrote:

quoted

quoted

2026年6月27日 07:40，Kuniyuki Iwashima [off-list ref] 写道：

On Fri, Jun 26, 2026 at 2:40 AM [off-list ref] wrote:

quoted

From: luoxuanqiang <redacted>

IP_LOCAL_PORT_RANGE lets applications override the netns ephemeral port
range on a per-socket basis.  __inet_hash_connect() already treats such a
range as an explicit application partition and scans it with step 1 [1].

Do the same in inet_csk_find_open_port():

What's the use case of IP_LOCAL_PORT_RANGE + bind(, 0)
without IP_BIND_ADDRESS_NO_PORT ?

Hi Kuniyuki,

Thanks for the question!

The use case is when an application wants to restrict ephemeral port
allocation to a socket-local IP_LOCAL_PORT_RANGE, but still needs
bind(..., 0) to allocate and reserve a local port immediately.

IP_LOCAL_PORT_RANGE was introduced for connect().

Unlike connect(), bind() occupies the port without SO_REUSEADDR/PORT,
so I don't think the step 1 or 2 makes any difference.

Hi Kuniyuki,

That's a fair point — bind() takes exclusive ownership of the port
without SO_REUSEADDR/PORT, so the parity split only changes the scan
order, not the set of ports bind() can pick.  Correctness-wise there is
no difference between step 1 and step 2 here.

There are a couple of smaller things that made me think it is still
worth aligning the two paths, though:

- inet_csk_find_open_port() already consumes the narrowed range from
   IP_LOCAL_PORT_RANGE since commit 91d0b78c5177f ("inet: Add
   IP_LOCAL_PORT_RANGE socket option"), so the bind path isn't
   insulated from the option.  It just didn't pick up the relaxed scan
   step that __inet_hash_connect() got in commit 207184853dbdb
   ("tcp/dccp: change source port selection at connect() time").  Eric
   even noted at the end of that commit:

     "A similar change can be done in inet_csk_find_open_port() if
      needed."

   So this felt more like completing the companion change than adding
   something new.

- The entropy argument from commit 207184853dbdb applies equally here:
   the parity split drops one bit of the 16-bit sport for RSS hashing.
   Whether the port came from connect() or bind() doesn't matter to the
   NIC, and losing that bit hurts more when the application has already
   shrunk its port space with IP_LOCAL_PORT_RANGE.

- When IP_BIND_ADDRESS_NO_PORT is not set, plain bind(, 0) reserves a
   port immediately through inet_csk_find_open_port().  If the same
   application also uses connect() on other sockets within the same
   IP_LOCAL_PORT_RANGE, connect() now scans the full range while bind()
   still biases toward odd ports — so the parity heuristic works against
   itself inside the application's own partition.

Does that make sense, or am I over-thinking the consistency angle?

Thanks,
Xuanqiang

quoted

IP_BIND_ADDRESS_NO_PORT is useful when the application can defer port
allocation until connect(), but it changes this behavior: bind(..., 0)
does not reserve a port in that case. So it is not a replacement for
applications that need the local port before connect(), for example to
publish it to another component or set up local policy.

This patch is also intended to keep the bind(..., 0) path consistent with
Eric's earlier change in __inet_hash_connect().

Thanks,
Xuanqiang