netdev - Re: [PATCH net-next] tcp: use RCU in __inet{6}_check

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL+tcoAY1xKgdFzQDcU4LJ7wEZ7oFSaY_aqwtiw4MV-W1RMBWg@mail.gmail.com>
Date: Sun, 2 Mar 2025 08:16:41 +0800
From: Jason Xing <kerneljasonxing@...il.com>
To: Eric Dumazet <edumazet@...gle.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, 
	Paolo Abeni <pabeni@...hat.com>, Neal Cardwell <ncardwell@...gle.com>, 
	Kuniyuki Iwashima <kuniyu@...zon.com>, Simon Horman <horms@...nel.org>, netdev@...r.kernel.org, 
	eric.dumazet@...il.com
Subject: Re: [PATCH net-next] tcp: use RCU in __inet{6}_check_established()

On Sun, Mar 2, 2025 at 3:46 AM Eric Dumazet <edumazet@...gle.com> wrote:
>
> When __inet_hash_connect() has to try many 4-tuples before
> finding an available one, we see a high spinlock cost from
> __inet_check_established() and/or __inet6_check_established().
>
> This patch adds an RCU lookup to avoid the spinlock
> acquisition if the 4-tuple is found in the hash table.
>
> Note that there are still spin_lock_bh() calls in
> __inet_hash_connect() to protect inet_bind_hashbucket,
> this will be fixed in a future patch.
>
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>

Reviewed-by: Jason Xing <kerneljasonxing@...il.com>

It can introduce extra system overhead in most cases because it takes
effect only when the socket is not unique in the hash table. I'm not
sure what the probability of seeing this case is in reality in
general. Considering performing a look-up seems not to consume much, I
think it looks good to me. Well, it's the only one I'm a bit worried
about.

As you said, it truly mitigates the huge contention in the earlier
mentioned case where the available port resources are becoming rare.
We've encountered this situation causing high cpu load before. Thanks
for the optimization!

Thanks,
Jason