From: Jonathan Kowalski <bl0pbl33p@gmail.com> To: Joel Fernandes <joel@joelfernandes.org> Cc: Jann Horn <jannh@google.com>, Christian Brauner <christian@brauner.io>, Daniel Colascione <dancol@google.com>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Andy Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, "Serge E. Hallyn" <serge@hallyn.com>, "Eric W. Biederman" <ebiederm@xmission.com>, Linux API <linux-api@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>, Alexey Dobriyan <adobriyan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Michael Kerrisk-manpages <mtk.manpages@gmail.com>, "Dmitry V. Levin" <ldv@altlinux.org>, Andrew Morton <akpm@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>, Aleksa Sarai <cyphar@cyphar.com>, Al Viro <viro@zeniv.linux.org.uk> Subject: Re: [PATCH 0/4] pid: add pidctl() Date: Mon, 25 Mar 2019 21:54:58 +0000 [thread overview] Message-ID: <CAGLj2rEODAg+Y5D5Oxy3Gp-Yg6mqeisPnLQJ334TWSdrPW1L7A@mail.gmail.com> (raw) In-Reply-To: <20190325214338.GA16969@google.com> On Mon, Mar 25, 2019 at 9:43 PM Joel Fernandes <joel@joelfernandes.org> wrote: > > On Mon, Mar 25, 2019 at 10:19:26PM +0100, Jann Horn wrote: > > On Mon, Mar 25, 2019 at 10:11 PM Joel Fernandes <joel@joelfernandes.org> wrote: > > > > But often you don't just want to wait for a single thing to happen; > > you want to wait for many things at once, and react as soon as any one > > of them happens. This is why the kernel has epoll and all the other > > "wait for event on FD" APIs. If waiting for a process isn't possible > > with fd-based APIs like epoll, users of this API have to spin up > > useless helper threads. > > This is true. I almost forgot about the polling requirement, sorry. So then a > new syscall it is.. About what to wait for, that can be a separate parameter > to pidfd_wait then. > This introduces a time window where the process changes state between "get pidfd" and "setup waitfd", it would be simpler if the pidfd itself supported .poll and on termination the exit status was made readable from the file descriptor. Further, in the clone4 patchset, there was a mechanism to autoreap such a process so that it does not interfere with waiting a process does normally. How do you intend to handle this case if anyone except the parent is wanting to *wait* on the process (a second process, without reaping, so as to not disrupt any waiting in the parent), and for things like libraries that finally can manage their own set of process when pidfd_clone is added, by excluding this process from the process's normal wait handling logic. Moreover, should anyone except the parent process be allowed to open a readable pidfd (or waitfd), without additional capabilities? > Thanks. > > - Joel >
WARNING: multiple messages have this Message-ID (diff)
From: Jonathan Kowalski <bl0pbl33p@gmail.com> To: Joel Fernandes <joel@joelfernandes.org> Cc: Jann Horn <jannh@google.com>, Christian Brauner <christian@brauner.io>, Daniel Colascione <dancol@google.com>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Andy Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, "Serge E. Hallyn" <serge@hallyn.com>, "Eric W. Biederman" <ebiederm@xmission.com>, Linux API <linux-api@vger.kernel.org>, linux-kernel <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, Kees Cook <keescook@chromium.org>, Alexey Dobriyan <adobriyan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Michael Kerrisk-manpages <mtk.manpages@gmail.com>, "Dmitry V. Levin" <ldv@altlinux.org>, Andrew Morton <akpm@linux-foundation.org>, Oleg Nesterov <oleg@redhat.com>, Nagarathnam Muthusamy <nagarathnam.muthusam> Subject: Re: [PATCH 0/4] pid: add pidctl() Date: Mon, 25 Mar 2019 21:54:58 +0000 [thread overview] Message-ID: <CAGLj2rEODAg+Y5D5Oxy3Gp-Yg6mqeisPnLQJ334TWSdrPW1L7A@mail.gmail.com> (raw) In-Reply-To: <20190325214338.GA16969@google.com> On Mon, Mar 25, 2019 at 9:43 PM Joel Fernandes <joel@joelfernandes.org> wrote: > > On Mon, Mar 25, 2019 at 10:19:26PM +0100, Jann Horn wrote: > > On Mon, Mar 25, 2019 at 10:11 PM Joel Fernandes <joel@joelfernandes.org> wrote: > > > > But often you don't just want to wait for a single thing to happen; > > you want to wait for many things at once, and react as soon as any one > > of them happens. This is why the kernel has epoll and all the other > > "wait for event on FD" APIs. If waiting for a process isn't possible > > with fd-based APIs like epoll, users of this API have to spin up > > useless helper threads. > > This is true. I almost forgot about the polling requirement, sorry. So then a > new syscall it is.. About what to wait for, that can be a separate parameter > to pidfd_wait then. > This introduces a time window where the process changes state between "get pidfd" and "setup waitfd", it would be simpler if the pidfd itself supported .poll and on termination the exit status was made readable from the file descriptor. Further, in the clone4 patchset, there was a mechanism to autoreap such a process so that it does not interfere with waiting a process does normally. How do you intend to handle this case if anyone except the parent is wanting to *wait* on the process (a second process, without reaping, so as to not disrupt any waiting in the parent), and for things like libraries that finally can manage their own set of process when pidfd_clone is added, by excluding this process from the process's normal wait handling logic. Moreover, should anyone except the parent process be allowed to open a readable pidfd (or waitfd), without additional capabilities? > Thanks. > > - Joel >
next prev parent reply other threads:[~2019-03-25 21:55 UTC|newest] Thread overview: 77+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-25 16:20 [PATCH 0/4] pid: add pidctl() Christian Brauner 2019-03-25 16:20 ` [PATCH 1/4] Make anon_inodes unconditional Christian Brauner 2019-03-25 16:20 ` [PATCH 2/4] pid: add pidctl() Christian Brauner 2019-03-25 17:20 ` Mika Penttilä 2019-03-25 19:59 ` Christian Brauner 2019-03-25 19:59 ` Christian Brauner 2019-03-25 18:18 ` Jann Horn 2019-03-25 18:18 ` Jann Horn 2019-03-25 19:58 ` Christian Brauner 2019-03-25 19:58 ` Christian Brauner 2019-03-26 16:07 ` Joel Fernandes 2019-03-26 16:07 ` Joel Fernandes 2019-03-26 16:15 ` Christian Brauner 2019-03-26 16:15 ` Christian Brauner 2019-03-25 16:20 ` [PATCH 3/4] signal: support pidctl() with pidfd_send_signal() Christian Brauner 2019-03-25 18:28 ` Jonathan Kowalski 2019-03-25 18:28 ` Jonathan Kowalski 2019-03-25 20:05 ` Christian Brauner 2019-03-25 20:05 ` Christian Brauner 2019-03-25 18:39 ` Jann Horn 2019-03-25 18:39 ` Jann Horn 2019-03-25 19:41 ` Christian Brauner 2019-03-25 19:41 ` Christian Brauner 2019-03-25 16:20 ` [PATCH 4/4] tests: add pidctl() tests Christian Brauner 2019-03-25 16:48 ` [PATCH 0/4] pid: add pidctl() Daniel Colascione 2019-03-25 16:48 ` Daniel Colascione 2019-03-25 17:05 ` Konstantin Khlebnikov 2019-03-25 17:07 ` Daniel Colascione 2019-03-25 17:07 ` Daniel Colascione 2019-03-25 17:36 ` Joel Fernandes 2019-03-25 17:36 ` Joel Fernandes 2019-03-25 17:53 ` Daniel Colascione 2019-03-25 17:53 ` Daniel Colascione 2019-03-25 18:19 ` Jonathan Kowalski 2019-03-25 18:19 ` Jonathan Kowalski 2019-03-25 18:57 ` Daniel Colascione 2019-03-25 18:57 ` Daniel Colascione 2019-03-25 19:42 ` Jonathan Kowalski 2019-03-25 19:42 ` Jonathan Kowalski 2019-03-25 20:14 ` Daniel Colascione 2019-03-25 20:14 ` Daniel Colascione 2019-03-25 20:34 ` Jann Horn 2019-03-25 20:34 ` Jann Horn 2019-03-25 20:40 ` Jonathan Kowalski 2019-03-25 20:40 ` Jonathan Kowalski 2019-03-25 21:14 ` Jonathan Kowalski 2019-03-25 21:14 ` Jonathan Kowalski 2019-03-25 21:15 ` Jann Horn 2019-03-25 21:15 ` Jann Horn 2019-03-25 20:40 ` Christian Brauner 2019-03-25 20:40 ` Christian Brauner 2019-03-25 20:15 ` Christian Brauner 2019-03-25 20:15 ` Christian Brauner 2019-03-25 21:11 ` Joel Fernandes 2019-03-25 21:11 ` Joel Fernandes 2019-03-25 21:17 ` Daniel Colascione 2019-03-25 21:17 ` Daniel Colascione 2019-03-25 21:19 ` Jann Horn 2019-03-25 21:19 ` Jann Horn 2019-03-25 21:43 ` Joel Fernandes 2019-03-25 21:43 ` Joel Fernandes 2019-03-25 21:54 ` Jonathan Kowalski [this message] 2019-03-25 21:54 ` Jonathan Kowalski 2019-03-25 22:07 ` Daniel Colascione 2019-03-25 22:07 ` Daniel Colascione 2019-03-25 22:37 ` Jonathan Kowalski 2019-03-25 22:37 ` Jonathan Kowalski 2019-03-25 23:14 ` Daniel Colascione 2019-03-25 23:14 ` Daniel Colascione 2019-03-26 3:03 ` Joel Fernandes 2019-03-26 3:03 ` Joel Fernandes 2019-03-25 16:56 ` David Howells 2019-03-25 16:56 ` David Howells 2019-03-25 16:58 ` Daniel Colascione 2019-03-25 16:58 ` Daniel Colascione 2019-03-25 23:39 ` Andy Lutomirski 2019-03-25 23:39 ` Andy Lutomirski
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAGLj2rEODAg+Y5D5Oxy3Gp-Yg6mqeisPnLQJ334TWSdrPW1L7A@mail.gmail.com \ --to=bl0pbl33p@gmail.com \ --cc=adobriyan@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=christian@brauner.io \ --cc=cyphar@cyphar.com \ --cc=dancol@google.com \ --cc=dhowells@redhat.com \ --cc=ebiederm@xmission.com \ --cc=jannh@google.com \ --cc=joel@joelfernandes.org \ --cc=keescook@chromium.org \ --cc=khlebnikov@yandex-team.ru \ --cc=ldv@altlinux.org \ --cc=linux-api@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=luto@kernel.org \ --cc=mtk.manpages@gmail.com \ --cc=nagarathnam.muthusamy@oracle.com \ --cc=oleg@redhat.com \ --cc=serge@hallyn.com \ --cc=tglx@linutronix.de \ --cc=viro@zeniv.linux.org.uk \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.