[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230811112911.GA22566@redhat.com>
Date: Fri, 11 Aug 2023 13:29:11 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Christian Brauner <brauner@...nel.org>
Cc: David Rheinsberg <david@...dahead.eu>,
linux-kernel@...r.kernel.org, Jan Kara <jack@...e.cz>,
Kees Cook <keescook@...omium.org>,
Alexander Mikhalitsyn <alexander@...alicyn.com>,
Luca Boccassi <bluca@...ian.org>
Subject: Re: [PATCH] pid: allow pidfds for reaped tasks
Hi Christian,
Sorry for delay, I've just returned from vacation and I am slowly
crawling my email backlog.
On 08/07, Christian Brauner wrote:
>
> > int pidfd_prepare(struct pid *pid, unsigned int flags, struct file **ret)
> > {
> > - if (!pid || !pid_has_task(pid, PIDTYPE_TGID))
> > + if (!pid)
> > + return -EINVAL;
> > +
> > + /*
> > + * Non thread-group leaders cannot have pidfds, but we allow them for
> > + * reaped thread-group leaders.
> > + */
> > + if (pid_has_task(pid, PIDTYPE_PID) && !pid_has_task(pid, PIDTYPE_TGID))
> > return -EINVAL;
>
> TL;DR userspace wants to be able to get a pidfd to an already reaped
> thread-group leader. I don't see any issues with this.
I guess I need to read the whole thread carefully, but right now
I don't understand this patch and the problem...
OK, suppose we have a group leader L with pid 100 and its sub-thread
T with pid 101.
With this patch pidfd_open(101) can succeed if T exits right after
find_get_pid(101) because pid_has_task(pid, PIDTYPE_PID) above will
fail, right?
This looks wrong, 101 was never a leader pid...
Oleg.
Powered by blists - more mailing lists