linux-kernel - Re: [PATCH RFC 2/4] net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer

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: <20250424-chipsatz-verpennen-afa9e213e332@brauner>
Date: Thu, 24 Apr 2025 17:19:28 +0200
From: Christian Brauner <brauner@...nel.org>
To: David Rheinsberg <david@...dahead.eu>
Cc: Oleg Nesterov <oleg@...hat.com>, Kuniyuki Iwashima <kuniyu@...zon.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, netdev@...r.kernel.org, 
	Jan Kara <jack@...e.cz>, Alexander Mikhalitsyn <alexander@...alicyn.com>, 
	Luca Boccassi <bluca@...ian.org>, Lennart Poettering <lennart@...ttering.net>, 
	Daan De Meyer <daan.j.demeyer@...il.com>, Mike Yuan <me@...dnzj.com>
Subject: Re: [PATCH RFC 2/4] net, pidfs: prepare for handing out pidfds for
 reaped sk->sk_peer_pid

On Thu, Apr 24, 2025 at 02:44:13PM +0200, David Rheinsberg wrote:
> Hi
> 
> On Thu, Apr 24, 2025, at 2:24 PM, Christian Brauner wrote:
> [...]
> > Link: 
> > https://lore.kernel.org/lkml/20230807085203.819772-1-david@readahead.eu 
> > [1]
> > Signed-off-by: Christian Brauner <brauner@...nel.org>
> 
> Very nice! Highly appreciated!
> 
> > ---
> >  net/unix/af_unix.c | 90 
> > +++++++++++++++++++++++++++++++++++++++++++++++-------
> >  1 file changed, 79 insertions(+), 11 deletions(-)
> >
> > diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
> > index f78a2492826f..83b5aebf499e 100644
> > --- a/net/unix/af_unix.c
> > +++ b/net/unix/af_unix.c
> > @@ -100,6 +100,7 @@
> >  #include <linux/splice.h>
> >  #include <linux/string.h>
> >  #include <linux/uaccess.h>
> > +#include <linux/pidfs.h>
> >  #include <net/af_unix.h>
> >  #include <net/net_namespace.h>
> >  #include <net/scm.h>
> > @@ -643,6 +644,14 @@ static void unix_sock_destructor(struct sock *sk)
> >  		return;
> >  	}
> > 
> > +	if (sock_flag(sk, SOCK_RCU_FREE)) {
> > +		pr_info("Attempting to release RCU protected socket with sleeping 
> > locks: %p\n", sk);
> > +		return;
> > +	}
> 
> unix-sockets do not use `SOCK_RCU_FREE`, but even if they did, doesn't
> this flag imply that the destructor is delayed via `call_rcu`, and
> thus *IS* allowed to sleep? And then, sleeping in the destructor is
> always safe, isn't it? `SOCK_RCU_FREE` just guarantees that it is
> delayed for at least an RCU grace period, right? Not sure, what you
> are getting at here, but I might be missing something obvious as well.

Callbacks run from call_rcu() can be called from softirq context and in
general are not allowed to block. That's what queue_rcu_work() is for
which uses system_unbound_wq.

> 
> Regardless, wouldn't you want WARN_ON_ONCE() rather than pr_info?

Sure.