[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190725102156.nqnngsrb6dwmyztb@brauner.io>
Date: Thu, 25 Jul 2019 12:21:56 +0200
From: Christian Brauner <christian@...uner.io>
To: Oleg Nesterov <oleg@...hat.com>
Cc: linux-kernel@...r.kernel.org, arnd@...db.de, ebiederm@...ssion.com,
keescook@...omium.org, joel@...lfernandes.org, tglx@...utronix.de,
tj@...nel.org, dhowells@...hat.com, jannh@...gle.com,
luto@...nel.org, akpm@...ux-foundation.org, cyphar@...har.com,
torvalds@...ux-foundation.org, viro@...iv.linux.org.uk,
kernel-team@...roid.com, linux-api@...r.kernel.org
Subject: Re: [PATCH 2/5] pidfd: add pidfd_wait()
On Thu, Jul 25, 2019 at 12:16:27PM +0200, Oleg Nesterov wrote:
> On 07/24, Christian Brauner wrote:
> >
> > +SYSCALL_DEFINE6(pidfd_wait, int, pidfd, int __user *, stat_addr,
> > + siginfo_t __user *, info, struct rusage __user *, ru,
> > + unsigned int, states, unsigned int, flags)
> > +{
>
> Oh, I too think that P_PIDFD makes more sense.
I have already updated the patch to introduce P_PIDFD.
>
> and could you explain in the changelog why? I am not arguing and if
> nothing else this is consistent with other pidfd features, but if you
> are parent/debugger you can't hit the problem with pid-reuse, unless
> you races with your sub-threads.
One of the things is that later on this will allow us to make it
possible to retrieve the exit status via waitid(P_PIDFD) for non-parent
processes if handed a _suitable_ pidfd that has this feature set. Maybe
even - if safe - make it possible to wait on a process as a non-parent.
And some tools just really want to do away with pids completely.
Christian
Powered by blists - more mailing lists