linux-kernel - Re: [RFC PATCH] pidfd: implement PIDFD_THREAD flag for pidfd

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: <20240129-autark-spachtel-c37fd31383cc@brauner>
Date: Mon, 29 Jan 2024 16:14:29 +0100
From: Christian Brauner <brauner@...nel.org>
To: Tycho Andersen <tycho@...ho.pizza>
Cc: Oleg Nesterov <oleg@...hat.com>, linux-kernel@...r.kernel.org, 
	linux-api@...r.kernel.org, Tycho Andersen <tandersen@...flix.com>, 
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [RFC PATCH] pidfd: implement PIDFD_THREAD flag for pidfd_open()

On Mon, Jan 29, 2024 at 07:31:35AM -0700, Tycho Andersen wrote:
> On Mon, Jan 29, 2024 at 02:41:11PM +0100, Christian Brauner wrote:
> > On Mon, Jan 29, 2024 at 12:23:15PM +0100, Oleg Nesterov wrote:
> > > --- a/kernel/signal.c
> > > +++ b/kernel/signal.c
> > > @@ -2051,7 +2051,8 @@ bool do_notify_parent(struct task_struct *tsk, int sig)
> > >  	WARN_ON_ONCE(!tsk->ptrace &&
> > >  	       (tsk->group_leader != tsk || !thread_group_empty(tsk)));
> > >  	/*
> > > -	 * tsk is a group leader and has no threads, wake up the pidfd waiters.
> > > +	 * tsk is a group leader and has no threads, wake up the !PIDFD_THREAD
> > > +	 * waiters.
> > >  	 */
> > >  	if (thread_group_empty(tsk))
> > >  		do_notify_pidfd(tsk);
> > > @@ -3926,6 +3927,7 @@ SYSCALL_DEFINE4(pidfd_send_signal, int, pidfd, int, sig,
> > >  		prepare_kill_siginfo(sig, &kinfo);
> > >  	}
> > >  
> > > +	/* TODO: respect PIDFD_THREAD */
> > 
> > So I've been thinking about this at the end of last week. Do we need to
> > give userspace a way to send a thread-group wide signal even when a
> > PIDFD_THREAD pidfd is passed? Or should we just not worry about this
> > right now and wait until someone needs this?
> 
> I don't need it currently, but it would have been handy for some of
> the tests I wrote.
> 
> Should I fix those up and send them too on top of Oleg's v2?

Sure, I don't mind.