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: <1d9d20d9e41b351114f4e09f2d394c4fa8f03403.camel@redhat.com>
Date: Tue, 12 Sep 2023 18:58:54 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: Eric Dumazet <edumazet@...gle.com>, "David S . Miller"
 <davem@...emloft.net>,  Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org, Soheil Hassas Yeganeh <soheil@...gle.com>, Neal
 Cardwell <ncardwell@...gle.com>, Yuchung Cheng <ycheng@...gle.com>,
 eric.dumazet@...il.com
Subject: Re: [PATCH net-next 3/4] net: call prot->release_cb() when
 processing backlog

On Mon, 2023-09-11 at 17:05 +0000, Eric Dumazet wrote:
> __sk_flush_backlog() / sk_flush_backlog() are used
> when TCP recvmsg()/sendmsg() process large chunks,
> to not let packets in the backlog too long.
> 
> It makes sense to call tcp_release_cb() to also
> process actions held in sk->sk_tsq_flags for smoother
> scheduling.
> 
> Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> ---
>  net/core/sock.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 21610e3845a5042f7c648ccb3e0d90126df20a0b..bb89b88bc1e8a042c4ee40b3c8345dc58cb1b369 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -3001,6 +3001,9 @@ void __sk_flush_backlog(struct sock *sk)
>  {
>  	spin_lock_bh(&sk->sk_lock.slock);
>  	__release_sock(sk);
> +
> +	if (sk->sk_prot->release_cb)
> +		sk->sk_prot->release_cb(sk);

Out of sheer curiosity, I'm wondering if adding an
indirect_call_wrapper here could make any difference?

I guess not much, and in any case it could be a follow-up.

Cheers,

Paolo


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ