From: Daniel Colascione <dancol@google.com> To: Christian Brauner <christian@brauner.io> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Jann Horn <jannh@google.com>, Joel Fernandes <joel@joelfernandes.org>, Andrew Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, "Serge E. Hallyn" <serge@hallyn.com>, Linux API <linux-api@vger.kernel.org>, Linux List Kernel Mailing <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, "Eric W. Biederman" <ebiederm@xmission.com>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Kees Cook <keescook@chromium.org>, Alexey Dobriyan <adobriyan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Michael Kerrisk-manpages <mtk.manpages@gmail.com>, Jonathan Kowalski <bl0pbl33p@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 v2 0/5] pid: add pidfd_open() Date: Sun, 31 Mar 2019 08:21:39 -0700 [thread overview] Message-ID: <CAKOZues=PUZzKWoL10qiaLXgbDwE0YjygSdf4ZZSZHvOYMO=3w@mail.gmail.com> (raw) In-Reply-To: <20190331150507.zpyugdvtmr6rgpda@brauner.io> On Sun, Mar 31, 2019 at 8:05 AM Christian Brauner <christian@brauner.io> wrote: > > On Sun, Mar 31, 2019 at 07:52:28AM -0700, Linus Torvalds wrote: > > On Sat, Mar 30, 2019 at 9:47 PM Jann Horn <jannh@google.com> wrote: > > > > > > Sure, given a pidfd_clone() syscall, as long as the parent of the > > > process is giving you a pidfd for it and you don't have to deal with > > > grandchildren created by fork() calls outside your control, that > > > works. > > > > Don't do pidfd_clone() and pidfd_wait(). > > > > Both of those existing system calls already get a "flags" argument. > > Just make a WPIDFD (for waitid) and CLONE_PIDFD (for clone) bit, and > > make the existing system calls just take/return a pidfd. > > Yes, that's one of the options I was considering but was afraid of > pitching it because of the very massive opposition I got > regarding"multiplexers". I'm perfectly happy with doing it this way. This approach is fine by me, FWIW. I like it more than a general-purpose pidctl. > Btw, the /proc/<pid> race issue that is mentioned constantly is simply > avoidable by placing the pid that the pidfd has stashed relative to the > callers' procfs mount's pid namespace in the pidfd's fdinfo. So there's > not even a need to really go through /proc/<pid> in the first place. A > caller wanting to get metadata access and avoid a race with pid > recycling can then simply do: > > int pidfd = pidfd_open(pid, 0); > int pid = parse_fdinfo("/proc/self/fdinfo/<pidfd>"); > int procpidfd = open("/proc/<pid>", ...); IMHO, it's worth documenting this procedure in the pidfd man page. > /* Test if process still exists by sending signal 0 through our pidfd. */ Are you planning on officially documenting this incantation in the pidfd man page? > int ret = pidfd_send_signal(pid, 0, NULL, PIDFD_SIGNAL_THREAD); > if (ret < 0 && errno == ESRCH) { > /* pid has been recycled and procpidfd refers to another process */ > } I was going to suggest that WNOHANG also works for this purpose, but that idea raises another question: normally, you can wait*(2) on a process only once. Are you imagining waitid on a pidfd succeeding more than one? ISTM that the pidfd would need to internally store not just a struct pid, but the exit status as well or some way to get to it.
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Colascione <dancol@google.com> To: Christian Brauner <christian@brauner.io> Cc: Linus Torvalds <torvalds@linux-foundation.org>, Jann Horn <jannh@google.com>, Joel Fernandes <joel@joelfernandes.org>, Andrew Lutomirski <luto@kernel.org>, David Howells <dhowells@redhat.com>, "Serge E. Hallyn" <serge@hallyn.com>, Linux API <linux-api@vger.kernel.org>, Linux List Kernel Mailing <linux-kernel@vger.kernel.org>, Arnd Bergmann <arnd@arndb.de>, "Eric W. Biederman" <ebiederm@xmission.com>, Konstantin Khlebnikov <khlebnikov@yandex-team.ru>, Kees Cook <keescook@chromium.org>, Alexey Dobriyan <adobriyan@gmail.com>, Thomas Gleixner <tglx@linutronix.de>, Michael Kerrisk-manpages <mtk.manpages@gmail.com>, Jonathan Kowalski <bl0pbl33p@gmail.com>, "Dmitry V. Levin" <ldv@altlinux.org>, Andrew Morton <akpm@linux-foundation.org>, Oleg Subject: Re: [PATCH v2 0/5] pid: add pidfd_open() Date: Sun, 31 Mar 2019 08:21:39 -0700 [thread overview] Message-ID: <CAKOZues=PUZzKWoL10qiaLXgbDwE0YjygSdf4ZZSZHvOYMO=3w@mail.gmail.com> (raw) In-Reply-To: <20190331150507.zpyugdvtmr6rgpda@brauner.io> On Sun, Mar 31, 2019 at 8:05 AM Christian Brauner <christian@brauner.io> wrote: > > On Sun, Mar 31, 2019 at 07:52:28AM -0700, Linus Torvalds wrote: > > On Sat, Mar 30, 2019 at 9:47 PM Jann Horn <jannh@google.com> wrote: > > > > > > Sure, given a pidfd_clone() syscall, as long as the parent of the > > > process is giving you a pidfd for it and you don't have to deal with > > > grandchildren created by fork() calls outside your control, that > > > works. > > > > Don't do pidfd_clone() and pidfd_wait(). > > > > Both of those existing system calls already get a "flags" argument. > > Just make a WPIDFD (for waitid) and CLONE_PIDFD (for clone) bit, and > > make the existing system calls just take/return a pidfd. > > Yes, that's one of the options I was considering but was afraid of > pitching it because of the very massive opposition I got > regarding"multiplexers". I'm perfectly happy with doing it this way. This approach is fine by me, FWIW. I like it more than a general-purpose pidctl. > Btw, the /proc/<pid> race issue that is mentioned constantly is simply > avoidable by placing the pid that the pidfd has stashed relative to the > callers' procfs mount's pid namespace in the pidfd's fdinfo. So there's > not even a need to really go through /proc/<pid> in the first place. A > caller wanting to get metadata access and avoid a race with pid > recycling can then simply do: > > int pidfd = pidfd_open(pid, 0); > int pid = parse_fdinfo("/proc/self/fdinfo/<pidfd>"); > int procpidfd = open("/proc/<pid>", ...); IMHO, it's worth documenting this procedure in the pidfd man page. > /* Test if process still exists by sending signal 0 through our pidfd. */ Are you planning on officially documenting this incantation in the pidfd man page? > int ret = pidfd_send_signal(pid, 0, NULL, PIDFD_SIGNAL_THREAD); > if (ret < 0 && errno == ESRCH) { > /* pid has been recycled and procpidfd refers to another process */ > } I was going to suggest that WNOHANG also works for this purpose, but that idea raises another question: normally, you can wait*(2) on a process only once. Are you imagining waitid on a pidfd succeeding more than one? ISTM that the pidfd would need to internally store not just a struct pid, but the exit status as well or some way to get to it.
next prev parent reply other threads:[~2019-03-31 15:21 UTC|newest] Thread overview: 158+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-03-29 15:54 [PATCH v2 0/5] pid: add pidfd_open() Christian Brauner 2019-03-29 15:54 ` [PATCH v2 1/5] Make anon_inodes unconditional Christian Brauner 2019-03-29 15:54 ` [PATCH v2 2/5] pid: add pidfd_open() Christian Brauner 2019-03-29 23:45 ` Jann Horn 2019-03-29 23:45 ` Jann Horn 2019-03-29 23:55 ` Christian Brauner 2019-03-29 23:55 ` Christian Brauner 2019-03-30 11:53 ` Jürg Billeter 2019-03-30 14:37 ` Christian Brauner 2019-03-30 14:51 ` Jonathan Kowalski 2019-03-30 14:51 ` Jonathan Kowalski 2019-03-29 15:54 ` [PATCH v2 3/5] signal: support pidfd_open() with pidfd_send_signal() Christian Brauner 2019-03-29 15:54 ` [PATCH v2 4/5] signal: PIDFD_SIGNAL_TID threads via pidfds Christian Brauner 2019-03-30 1:06 ` Jann Horn 2019-03-30 1:06 ` Jann Horn 2019-03-30 1:22 ` Christian Brauner 2019-03-30 1:22 ` Christian Brauner 2019-03-30 1:34 ` Christian Brauner 2019-03-30 1:34 ` Christian Brauner 2019-03-30 1:42 ` Christian Brauner 2019-03-30 1:42 ` Christian Brauner 2019-03-29 15:54 ` [PATCH v2 5/5] tests: add pidfd_open() tests Christian Brauner 2019-03-30 16:09 ` [PATCH v2 0/5] pid: add pidfd_open() Linus Torvalds 2019-03-30 16:09 ` Linus Torvalds 2019-03-30 16:11 ` Daniel Colascione 2019-03-30 16:11 ` Daniel Colascione 2019-03-30 16:16 ` Linus Torvalds 2019-03-30 16:16 ` Linus Torvalds 2019-03-30 16:18 ` Linus Torvalds 2019-03-30 16:18 ` Linus Torvalds 2019-03-31 1:07 ` Joel Fernandes 2019-03-31 1:07 ` Joel Fernandes 2019-03-31 2:34 ` Jann Horn 2019-03-31 2:34 ` Jann Horn 2019-03-31 4:08 ` Joel Fernandes 2019-03-31 4:08 ` Joel Fernandes 2019-03-31 4:46 ` Jann Horn 2019-03-31 4:46 ` Jann Horn 2019-03-31 14:52 ` Linus Torvalds 2019-03-31 14:52 ` Linus Torvalds 2019-03-31 15:05 ` Christian Brauner 2019-03-31 15:05 ` Christian Brauner 2019-03-31 15:21 ` Daniel Colascione [this message] 2019-03-31 15:21 ` Daniel Colascione 2019-03-31 15:33 ` Jonathan Kowalski 2019-03-31 15:33 ` Jonathan Kowalski 2019-03-30 16:19 ` Christian Brauner 2019-03-30 16:19 ` Christian Brauner 2019-03-30 16:24 ` Linus Torvalds 2019-03-30 16:24 ` Linus Torvalds 2019-03-30 16:34 ` Daniel Colascione 2019-03-30 16:34 ` Daniel Colascione 2019-03-30 16:38 ` Christian Brauner 2019-03-30 16:38 ` Christian Brauner 2019-03-30 17:04 ` Linus Torvalds 2019-03-30 17:04 ` Linus Torvalds 2019-03-30 17:12 ` Christian Brauner 2019-03-30 17:12 ` Christian Brauner 2019-03-30 17:24 ` Linus Torvalds 2019-03-30 17:24 ` Linus Torvalds 2019-03-30 17:37 ` Christian Brauner 2019-03-30 17:37 ` Christian Brauner 2019-03-30 17:50 ` Jonathan Kowalski 2019-03-30 17:50 ` Jonathan Kowalski 2019-03-30 17:52 ` Christian Brauner 2019-03-30 17:52 ` Christian Brauner 2019-03-30 17:59 ` Jonathan Kowalski 2019-03-30 17:59 ` Jonathan Kowalski 2019-03-30 18:02 ` Christian Brauner 2019-03-30 18:02 ` Christian Brauner 2019-03-30 18:00 ` Jann Horn 2019-03-30 18:00 ` Jann Horn 2019-03-31 20:09 ` Andy Lutomirski 2019-03-31 20:09 ` Andy Lutomirski 2019-03-31 21:03 ` Linus Torvalds 2019-03-31 21:03 ` Linus Torvalds 2019-03-31 21:10 ` Christian Brauner 2019-03-31 21:10 ` Christian Brauner 2019-03-31 21:17 ` Linus Torvalds 2019-03-31 21:17 ` Linus Torvalds 2019-03-31 22:03 ` Christian Brauner 2019-03-31 22:03 ` Christian Brauner 2019-03-31 22:16 ` Linus Torvalds 2019-03-31 22:16 ` Linus Torvalds 2019-03-31 22:33 ` Christian Brauner 2019-03-31 22:33 ` Christian Brauner 2019-04-01 0:52 ` Jann Horn 2019-04-01 0:52 ` Jann Horn 2019-04-01 8:47 ` Yann Droneaud 2019-04-01 8:47 ` Yann Droneaud 2019-04-01 10:03 ` Jonathan Kowalski 2019-04-01 10:03 ` Jonathan Kowalski 2019-03-31 23:40 ` Linus Torvalds 2019-03-31 23:40 ` Linus Torvalds 2019-04-01 0:09 ` Al Viro 2019-04-01 0:09 ` Al Viro 2019-04-01 0:18 ` Linus Torvalds 2019-04-01 0:18 ` Linus Torvalds 2019-04-01 0:21 ` Christian Brauner 2019-04-01 0:21 ` Christian Brauner 2019-04-01 6:37 ` Al Viro 2019-04-01 6:37 ` Al Viro 2019-04-01 6:41 ` Al Viro 2019-04-01 6:41 ` Al Viro 2019-03-31 22:03 ` Jonathan Kowalski 2019-03-31 22:03 ` Jonathan Kowalski 2019-04-01 2:13 ` Andy Lutomirski 2019-04-01 2:13 ` Andy Lutomirski 2019-04-01 11:40 ` Aleksa Sarai 2019-04-01 11:40 ` Aleksa Sarai 2019-04-01 15:36 ` Linus Torvalds 2019-04-01 15:36 ` Linus Torvalds 2019-04-01 15:47 ` Christian Brauner 2019-04-01 15:47 ` Christian Brauner 2019-04-01 15:55 ` Daniel Colascione 2019-04-01 15:55 ` Daniel Colascione 2019-04-01 16:01 ` Linus Torvalds 2019-04-01 16:01 ` Linus Torvalds 2019-04-01 16:13 ` Daniel Colascione 2019-04-01 16:13 ` Daniel Colascione 2019-04-01 19:42 ` Christian Brauner 2019-04-01 19:42 ` Christian Brauner 2019-04-01 21:30 ` Linus Torvalds 2019-04-01 21:30 ` Linus Torvalds 2019-04-01 21:58 ` Jonathan Kowalski 2019-04-01 21:58 ` Jonathan Kowalski 2019-04-01 22:13 ` Linus Torvalds 2019-04-01 22:13 ` Linus Torvalds 2019-04-01 22:34 ` Daniel Colascione 2019-04-01 22:34 ` Daniel Colascione 2019-04-01 16:07 ` Jonathan Kowalski 2019-04-01 16:07 ` Jonathan Kowalski 2019-04-01 16:15 ` Linus Torvalds 2019-04-01 16:15 ` Linus Torvalds 2019-04-01 16:27 ` Jonathan Kowalski 2019-04-01 16:27 ` Jonathan Kowalski 2019-04-01 16:21 ` Daniel Colascione 2019-04-01 16:21 ` Daniel Colascione 2019-04-01 16:29 ` Linus Torvalds 2019-04-01 16:29 ` Linus Torvalds 2019-04-01 16:45 ` Daniel Colascione 2019-04-01 16:45 ` Daniel Colascione 2019-04-01 17:00 ` David Laight 2019-04-01 17:00 ` David Laight 2019-04-01 17:32 ` Linus Torvalds 2019-04-01 17:32 ` Linus Torvalds 2019-04-02 11:03 ` Florian Weimer 2019-04-02 11:03 ` Florian Weimer 2019-04-01 16:10 ` Andy Lutomirski 2019-04-01 16:10 ` Andy Lutomirski 2019-04-01 12:04 ` Christian Brauner 2019-04-01 12:04 ` Christian Brauner 2019-04-01 13:43 ` Jann Horn 2019-04-01 13:43 ` Jann Horn 2019-03-31 21:19 ` Christian Brauner 2019-03-31 21:19 ` Christian Brauner 2019-03-30 16:37 ` Christian Brauner 2019-03-30 16:37 ` Christian Brauner
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='CAKOZues=PUZzKWoL10qiaLXgbDwE0YjygSdf4ZZSZHvOYMO=3w@mail.gmail.com' \ --to=dancol@google.com \ --cc=adobriyan@gmail.com \ --cc=akpm@linux-foundation.org \ --cc=arnd@arndb.de \ --cc=bl0pbl33p@gmail.com \ --cc=christian@brauner.io \ --cc=cyphar@cyphar.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=torvalds@linux-foundation.org \ --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.