| Message ID | 20190515100400.3450-1-christian@brauner.io (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/2] pid: add pidfd_open() | expand |
On Wed, May 15, 2019 at 12:04 PM Christian Brauner <christian@brauner.io> wrote: > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > process that is created via traditional fork()/clone() calls that is only > referenced by a PID: > > int pidfd = pidfd_open(1234, 0); > ret = pidfd_send_signal(pidfd, SIGSTOP, NULL, 0); > > With the introduction of pidfds through CLONE_PIDFD it is possible to > created pidfds at process creation time. > However, a lot of processes get created with traditional PID-based calls > such as fork() or clone() (without CLONE_PIDFD). For these processes a > caller can currently not create a pollable pidfd. This is a huge problem > for Android's low memory killer (LMK) and service managers such as systemd. > Both are examples of tools that want to make use of pidfds to get reliable > notification of process exit for non-parents (pidfd polling) and race-free > signal sending (pidfd_send_signal()). They intend to switch to this API for > process supervision/management as soon as possible. Having no way to get > pollable pidfds from PID-only processes is one of the biggest blockers for > them in adopting this api. With pidfd_open() making it possible to retrieve > pidfd for PID-based processes we enable them to adopt this api. > > In line with Arnd's recent changes to consolidate syscall numbers across > architectures, I have added the pidfd_open() syscall to all architectures > at the same time. > > Signed-off-by: Christian Brauner <christian@brauner.io> > arch/m68k/kernel/syscalls/syscall.tbl | 1 + Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Gr{oetje,eeting}s, Geert
Hi, Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit : > > diff --git a/kernel/pid.c b/kernel/pid.c > index 20881598bdfa..237d18d6ecb8 100644 > --- a/kernel/pid.c > +++ b/kernel/pid.c > @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct > pid_namespace *ns) > return idr_get_next(&ns->idr, &nr); > } > > +/** > + * pidfd_open() - Open new pid file descriptor. > + * > + * @pid: pid for which to retrieve a pidfd > + * @flags: flags to pass > + * > + * This creates a new pid file descriptor with the O_CLOEXEC flag set for > + * the process identified by @pid. Currently, the process identified by > + * @pid must be a thread-group leader. This restriction currently exists > + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot > + * be used with CLONE_THREAD) and pidfd polling (only supports thread group > + * leaders). > + * Would it be possible to create file descriptor with "restricted" operation ? - O_RDONLY: waiting for process completion allowed (for example) - O_WRONLY: sending process signal allowed For example, a process could send over a Unix socket a process a pidfd, allowing this to only wait for completion, but not sending signal ? I see the permission check is not done in pidfd_open(), so what prevent a user from sending a signal to another user owned process ? If it's in pidfd_send_signal(), then, passing the socket through SCM_RIGHT won't be useful if the target process is not owned by the same user, or root. > + * Return: On success, a cloexec pidfd is returned. > + * On error, a negative errno number will be returned. > + */ > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > +{ > + int fd, ret; > + struct pid *p; > + struct task_struct *tsk; > + > + if (flags) > + return -EINVAL; > + > + if (pid <= 0) > + return -EINVAL; > + > + p = find_get_pid(pid); > + if (!p) > + return -ESRCH; > + > + rcu_read_lock(); > + tsk = pid_task(p, PIDTYPE_PID); > + if (!tsk) > + ret = -ESRCH; > + else if (unlikely(!thread_group_leader(tsk))) > + ret = -EINVAL; > + else > + ret = 0; > + rcu_read_unlock(); > + > + fd = ret ?: pidfd_create(p); > + put_pid(p); > + return fd; > +} > + > void __init pid_idr_init(void) > { > /* Verify no one has done anything silly: */ Regards.
On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote: > Hi, > > Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit : > > > > diff --git a/kernel/pid.c b/kernel/pid.c > > index 20881598bdfa..237d18d6ecb8 100644 > > --- a/kernel/pid.c > > +++ b/kernel/pid.c > > @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct > > pid_namespace *ns) > > return idr_get_next(&ns->idr, &nr); > > } > > > > +/** > > + * pidfd_open() - Open new pid file descriptor. > > + * > > + * @pid: pid for which to retrieve a pidfd > > + * @flags: flags to pass > > + * > > + * This creates a new pid file descriptor with the O_CLOEXEC flag set for > > + * the process identified by @pid. Currently, the process identified by > > + * @pid must be a thread-group leader. This restriction currently exists > > + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot > > + * be used with CLONE_THREAD) and pidfd polling (only supports thread group > > + * leaders). > > + * > > Would it be possible to create file descriptor with "restricted" > operation ? > > - O_RDONLY: waiting for process completion allowed (for example) > - O_WRONLY: sending process signal allowed Yes, something like this is likely going to be possible in the future. We had discussion around this. But mapping this to O_RDONLY and O_WRONLY is not the right model. It makes more sense to have specialized flags that restrict actions. > > For example, a process could send over a Unix socket a process a pidfd, > allowing this to only wait for completion, but not sending signal ? > > I see the permission check is not done in pidfd_open(), so what prevent > a user from sending a signal to another user owned process ? That's supposed to be possible. You can do the same right now already with pids. Tools like LMK need this probably very much. Permission checking for signals is done at send time right now. And if you can't signal via a pid you can't signal via a pidfd as they're both subject to the same permissions checks. > > If it's in pidfd_send_signal(), then, passing the socket through > SCM_RIGHT won't be useful if the target process is not owned by the > same user, or root. > > > + * Return: On success, a cloexec pidfd is returned. > > + * On error, a negative errno number will be returned. > > + */ > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > +{ > > + int fd, ret; > > + struct pid *p; > > + struct task_struct *tsk; > > + > > + if (flags) > > + return -EINVAL; > > + > > + if (pid <= 0) > > + return -EINVAL; > > + > > + p = find_get_pid(pid); > > + if (!p) > > + return -ESRCH; > > + > > + rcu_read_lock(); > > + tsk = pid_task(p, PIDTYPE_PID); > > + if (!tsk) > > + ret = -ESRCH; > > + else if (unlikely(!thread_group_leader(tsk))) > > + ret = -EINVAL; > > + else > > + ret = 0; > > + rcu_read_unlock(); > > + > > + fd = ret ?: pidfd_create(p); > > + put_pid(p); > > + return fd; > > +} > > + > > void __init pid_idr_init(void) > > { > > /* Verify no one has done anything silly: */ > > Regards. > > -- > Yann Droneaud > OPTEYA > >
On 05/15, Christian Brauner wrote: > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > +{ > + int fd, ret; > + struct pid *p; > + struct task_struct *tsk; > + > + if (flags) > + return -EINVAL; > + > + if (pid <= 0) > + return -EINVAL; > + > + p = find_get_pid(pid); > + if (!p) > + return -ESRCH; > + > + rcu_read_lock(); > + tsk = pid_task(p, PIDTYPE_PID); You do not need find_get_pid() before rcu_lock and put_pid() at the end. You can just do find_vpid() under rcu_read_lock(). > + if (!tsk) > + ret = -ESRCH; > + else if (unlikely(!thread_group_leader(tsk))) > + ret = -EINVAL; it seems that you can do a single check tsk = pid_task(p, PIDTYPE_TGID); if (!tsk) ret = -ESRCH; this even looks more correct if we race with exec changing the leader. Oleg.
On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote: > On 05/15, Christian Brauner wrote: > > > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > +{ > > + int fd, ret; > > + struct pid *p; > > + struct task_struct *tsk; > > + > > + if (flags) > > + return -EINVAL; > > + > > + if (pid <= 0) > > + return -EINVAL; > > + > > + p = find_get_pid(pid); > > + if (!p) > > + return -ESRCH; > > + > > + rcu_read_lock(); > > + tsk = pid_task(p, PIDTYPE_PID); > > You do not need find_get_pid() before rcu_lock and put_pid() at the end. > You can just do find_vpid() under rcu_read_lock(). Will do. > > > + if (!tsk) > > + ret = -ESRCH; > > + else if (unlikely(!thread_group_leader(tsk))) > > + ret = -EINVAL; > > it seems that you can do a single check > > tsk = pid_task(p, PIDTYPE_TGID); > if (!tsk) > ret = -ESRCH; > > this even looks more correct if we race with exec changing the leader. The logic here being that you can only reach the thread_group leader from struct pid if PIDTYPE_PID == PIDTYPE_TGID for this struct pid? Thanks, Oleg. Christian
On 2019-05-15, Christian Brauner <christian@brauner.io> wrote: > On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote: > > Would it be possible to create file descriptor with "restricted" > > operation ? > > > > - O_RDONLY: waiting for process completion allowed (for example) > > - O_WRONLY: sending process signal allowed > > Yes, something like this is likely going to be possible in the future. > We had discussion around this. But mapping this to O_RDONLY and O_WRONLY > is not the right model. It makes more sense to have specialized flags > that restrict actions. Not to mention that the O_* flags have silly values which we shouldn't replicate in new syscalls IMHO.
On 05/15, Christian Brauner wrote: > > On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote: > > > > it seems that you can do a single check > > > > tsk = pid_task(p, PIDTYPE_TGID); > > if (!tsk) > > ret = -ESRCH; > > > > this even looks more correct if we race with exec changing the leader. > > The logic here being that you can only reach the thread_group leader > from struct pid if PIDTYPE_PID == PIDTYPE_TGID for this struct pid? Not exactly... it is not that PIDTYPE_PID == PIDTYPE_TGID for this pid, struct pid has no "type" or something like this. The logic is that pid->tasks[PIDTYPE_XXX] is the list of task which use this pid as "XXX" type. For example, clone(CLONE_THREAD) creates a pid which has a single non- empty list, pid->tasks[PIDTYPE_PID]. This pid can't be used as TGID or SID. So if pid_task(PIDTYPE_TGID) returns non-NULL we know that this pid was used for a group-leader, see copy_process() which does if (thread_group_leader(p)) attach_pid(p, PIDTYPE_TGID); If we race with exec which changes the leader pid_task(TGID) can return the old leader. We do not care, but this means that we should not check thread_group_leader(). Oleg.
Hi, Le mercredi 15 mai 2019 à 16:16 +0200, Christian Brauner a écrit : > On Wed, May 15, 2019 at 04:00:20PM +0200, Yann Droneaud wrote: > > Le mercredi 15 mai 2019 à 12:03 +0200, Christian Brauner a écrit : > > > diff --git a/kernel/pid.c b/kernel/pid.c > > > index 20881598bdfa..237d18d6ecb8 100644 > > > --- a/kernel/pid.c > > > +++ b/kernel/pid.c > > > @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct > > > pid_namespace *ns) > > > return idr_get_next(&ns->idr, &nr); > > > } > > > > > > +/** > > > + * pidfd_open() - Open new pid file descriptor. > > > + * > > > + * @pid: pid for which to retrieve a pidfd > > > + * @flags: flags to pass > > > + * > > > + * This creates a new pid file descriptor with the O_CLOEXEC flag set for > > > + * the process identified by @pid. Currently, the process identified by > > > + * @pid must be a thread-group leader. This restriction currently exists > > > + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot > > > + * be used with CLONE_THREAD) and pidfd polling (only supports thread group > > > + * leaders). > > > + * > > > > Would it be possible to create file descriptor with "restricted" > > operation ? > > > > - O_RDONLY: waiting for process completion allowed (for example) > > - O_WRONLY: sending process signal allowed > > Yes, something like this is likely going to be possible in the future. > We had discussion around this. But mapping this to O_RDONLY and O_WRONLY > is not the right model. It makes more sense to have specialized flags > that restrict actions. Yes, dedicated flags are the way to go. I've used the old open() flags here as examples as an echo of the O_CLOEXEC flag used in the comment. > > For example, a process could send over a Unix socket a process a pidfd, > > allowing this to only wait for completion, but not sending signal ? > > > > I see the permission check is not done in pidfd_open(), so what prevent > > a user from sending a signal to another user owned process ? > > That's supposed to be possible. You can do the same right now already > with pids. Tools like LMK need this probably very much. > Permission checking for signals is done at send time right now. > And if you can't signal via a pid you can't signal via a pidfd as > they're both subject to the same permissions checks. > I would have expect it to behave like most other file descriptor, permission check done at opening time, which allow more privileged process to open the file descriptor, then pass it to a less privileged process, or change its own privileged with setuid() and such. Then the less privileged process can act on behalf of the privileged process through the file descriptor. > > If it's in pidfd_send_signal(), then, passing the socket through > > SCM_RIGHT won't be useful if the target process is not owned by the > > same user, or root. > > If the permission check is done at sending time, the scenario above case cannot be implemented. Sending a pidfd through SCM_RIGHT is only useful if the receiver process is equally or more privileged than the sender then. For isolation purpose, I would have expect to be able to give a right to send a signal to a highly privileged process a specific less privileged process though Unix socket. But I can't come up with a specific use case. So I dunno. Regards.
On Wed, May 15, 2019 at 05:19:13PM +0200, Oleg Nesterov wrote: > On 05/15, Christian Brauner wrote: > > > > On Wed, May 15, 2019 at 04:38:58PM +0200, Oleg Nesterov wrote: > > > > > > it seems that you can do a single check > > > > > > tsk = pid_task(p, PIDTYPE_TGID); > > > if (!tsk) > > > ret = -ESRCH; > > > > > > this even looks more correct if we race with exec changing the leader. > > > > The logic here being that you can only reach the thread_group leader > > from struct pid if PIDTYPE_PID == PIDTYPE_TGID for this struct pid? > > Not exactly... it is not that PIDTYPE_PID == PIDTYPE_TGID for this pid, > struct pid has no "type" or something like this. > > The logic is that pid->tasks[PIDTYPE_XXX] is the list of task which use > this pid as "XXX" type. > > For example, clone(CLONE_THREAD) creates a pid which has a single non- > empty list, pid->tasks[PIDTYPE_PID]. This pid can't be used as TGID or > SID. > > So if pid_task(PIDTYPE_TGID) returns non-NULL we know that this pid was > used for a group-leader, see copy_process() which does Ah, this was what I was asking myself when I worked on thread-specific signal sending. This clarifies quite a lot of things! Though I wonder how one reliably gets a the PGID or SID from a PIDTYPE_PID. > > if (thread_group_leader(p)) > attach_pid(p, PIDTYPE_TGID); > > > If we race with exec which changes the leader pid_task(TGID) can return > the old leader. We do not care, but this means that we should not check > thread_group_leader(). Nice! Thank you, Oleg! :) Christian
On 05/15, Oleg Nesterov wrote: > > On 05/15, Christian Brauner wrote: > > > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > +{ > > + int fd, ret; > > + struct pid *p; > > + struct task_struct *tsk; > > + > > + if (flags) > > + return -EINVAL; > > + > > + if (pid <= 0) > > + return -EINVAL; > > + > > + p = find_get_pid(pid); > > + if (!p) > > + return -ESRCH; > > + > > + rcu_read_lock(); > > + tsk = pid_task(p, PIDTYPE_PID); > > You do not need find_get_pid() before rcu_lock and put_pid() at the end. > You can just do find_vpid() under rcu_read_lock(). Ah, sorry. Somehow I forgot you need to call pidfd_create(pid), you can't do this under rcu_read_lock(). So I was wrong, you can't avoid get/put_pid. Oleg.
On Wed, May 15, 2019 at 05:35:15PM +0200, Oleg Nesterov wrote: > On 05/15, Oleg Nesterov wrote: > > > > On 05/15, Christian Brauner wrote: > > > > > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > > +{ > > > + int fd, ret; > > > + struct pid *p; > > > + struct task_struct *tsk; > > > + > > > + if (flags) > > > + return -EINVAL; > > > + > > > + if (pid <= 0) > > > + return -EINVAL; > > > + > > > + p = find_get_pid(pid); > > > + if (!p) > > > + return -ESRCH; > > > + > > > + rcu_read_lock(); > > > + tsk = pid_task(p, PIDTYPE_PID); > > > > You do not need find_get_pid() before rcu_lock and put_pid() at the end. > > You can just do find_vpid() under rcu_read_lock(). > > Ah, sorry. Somehow I forgot you need to call pidfd_create(pid), you can't > do this under rcu_read_lock(). > > So I was wrong, you can't avoid get/put_pid. Yeah, I haven't made any changes yet. Christian
On Wed, May 15, 2019 at 3:04 AM Christian Brauner <christian@brauner.io> wrote: > > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > process that is created via traditional fork()/clone() calls that is only > referenced by a PID: Thanks for doing this work. I'm really looking forward to this new approach to process management. > int pidfd = pidfd_open(1234, 0); > ret = pidfd_send_signal(pidfd, SIGSTOP, NULL, 0); > > With the introduction of pidfds through CLONE_PIDFD it is possible to > created pidfds at process creation time. > However, a lot of processes get created with traditional PID-based calls > such as fork() or clone() (without CLONE_PIDFD). For these processes a > caller can currently not create a pollable pidfd. This is a huge problem > for Android's low memory killer (LMK) and service managers such as systemd. > Both are examples of tools that want to make use of pidfds to get reliable > notification of process exit for non-parents (pidfd polling) and race-free > signal sending (pidfd_send_signal()). They intend to switch to this API for > process supervision/management as soon as possible. Having no way to get > pollable pidfds from PID-only processes is one of the biggest blockers for > them in adopting this api. With pidfd_open() making it possible to retrieve > pidfd for PID-based processes we enable them to adopt this api. > > In line with Arnd's recent changes to consolidate syscall numbers across > architectures, I have added the pidfd_open() syscall to all architectures > at the same time. I'm glad it's easier now. > arch/alpha/kernel/syscalls/syscall.tbl | 1 + > arch/arm64/include/asm/unistd32.h | 2 + > arch/ia64/kernel/syscalls/syscall.tbl | 1 + > arch/m68k/kernel/syscalls/syscall.tbl | 1 + > arch/microblaze/kernel/syscalls/syscall.tbl | 1 + > arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + > arch/parisc/kernel/syscalls/syscall.tbl | 1 + > arch/powerpc/kernel/syscalls/syscall.tbl | 1 + > arch/s390/kernel/syscalls/syscall.tbl | 1 + > arch/sh/kernel/syscalls/syscall.tbl | 1 + > arch/sparc/kernel/syscalls/syscall.tbl | 1 + > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > arch/xtensa/kernel/syscalls/syscall.tbl | 1 + It'd be nice to arrange the system call tables so that we need to change only one file when adding a new system call. [Snip system call wiring] > --- a/include/linux/pid.h > +++ b/include/linux/pid.h > @@ -67,6 +67,7 @@ struct pid > extern struct pid init_struct_pid; > > extern const struct file_operations pidfd_fops; > +extern int pidfd_create(struct pid *pid); > > static inline struct pid *get_pid(struct pid *pid) > { > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > index e2870fe1be5b..989055e0b501 100644 > --- a/include/linux/syscalls.h > +++ b/include/linux/syscalls.h > @@ -929,6 +929,7 @@ asmlinkage long sys_clock_adjtime32(clockid_t which_clock, > struct old_timex32 __user *tx); > asmlinkage long sys_syncfs(int fd); > asmlinkage long sys_setns(int fd, int nstype); > +asmlinkage long sys_pidfd_open(pid_t pid, unsigned int flags); > asmlinkage long sys_sendmmsg(int fd, struct mmsghdr __user *msg, > unsigned int vlen, unsigned flags); > asmlinkage long sys_process_vm_readv(pid_t pid, > diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h > index dee7292e1df6..94a257a93d20 100644 > --- a/include/uapi/asm-generic/unistd.h > +++ b/include/uapi/asm-generic/unistd.h > @@ -832,9 +832,11 @@ __SYSCALL(__NR_io_uring_setup, sys_io_uring_setup) > __SYSCALL(__NR_io_uring_enter, sys_io_uring_enter) > #define __NR_io_uring_register 427 > __SYSCALL(__NR_io_uring_register, sys_io_uring_register) > +#define __NR_pidfd_open 428 > +__SYSCALL(__NR_pidfd_open, sys_pidfd_open) > > #undef __NR_syscalls > -#define __NR_syscalls 428 > +#define __NR_syscalls 429 > > /* > * 32 bit systems traditionally used different > diff --git a/kernel/fork.c b/kernel/fork.c > index 737db1828437..980cc1d2b8d4 100644 > --- a/kernel/fork.c > +++ b/kernel/fork.c > @@ -1714,7 +1714,7 @@ const struct file_operations pidfd_fops = { > * Return: On success, a cloexec pidfd is returned. > * On error, a negative errno number will be returned. > */ > -static int pidfd_create(struct pid *pid) > +int pidfd_create(struct pid *pid) > { > int fd; > > diff --git a/kernel/pid.c b/kernel/pid.c > index 20881598bdfa..237d18d6ecb8 100644 > --- a/kernel/pid.c > +++ b/kernel/pid.c > @@ -38,6 +38,7 @@ > #include <linux/syscalls.h> > #include <linux/proc_ns.h> > #include <linux/proc_fs.h> > +#include <linux/sched/signal.h> > #include <linux/sched/task.h> > #include <linux/idr.h> > > @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct pid_namespace *ns) > return idr_get_next(&ns->idr, &nr); > } > > +/** > + * pidfd_open() - Open new pid file descriptor. > + * > + * @pid: pid for which to retrieve a pidfd > + * @flags: flags to pass > + * > + * This creates a new pid file descriptor with the O_CLOEXEC flag set for > + * the process identified by @pid. Currently, the process identified by > + * @pid must be a thread-group leader. This restriction currently exists > + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot > + * be used with CLONE_THREAD) and pidfd polling (only supports thread group > + * leaders). > + * > + * Return: On success, a cloexec pidfd is returned. > + * On error, a negative errno number will be returned. > + */ > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > +{ > + int fd, ret; > + struct pid *p; > + struct task_struct *tsk; > + > + if (flags) > + return -EINVAL; If we support blocking operations on pidfds, we'll want to be able to put them in non-blocking mode. Does it make sense to accept and ignore O_NONBLOCK here now? > + if (pid <= 0) > + return -EINVAL; WDYT of defining pid == 0 to mean "open myself"? > + p = find_get_pid(pid); > + if (!p) > + return -ESRCH; > + > + rcu_read_lock(); > + tsk = pid_task(p, PIDTYPE_PID); > + if (!tsk) > + ret = -ESRCH; > + else if (unlikely(!thread_group_leader(tsk))) > + ret = -EINVAL; > + else > + ret = 0; > + rcu_read_unlock(); > + > + fd = ret ?: pidfd_create(p); > + put_pid(p); > + return fd; > +}
On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote: > On Wed, May 15, 2019 at 3:04 AM Christian Brauner <christian@brauner.io> wrote: > > > > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > > process that is created via traditional fork()/clone() calls that is only > > referenced by a PID: > > Thanks for doing this work. I'm really looking forward to this new > approach to process management. Thanks! Glad to hear! > > > int pidfd = pidfd_open(1234, 0); > > ret = pidfd_send_signal(pidfd, SIGSTOP, NULL, 0); > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > created pidfds at process creation time. > > However, a lot of processes get created with traditional PID-based calls > > such as fork() or clone() (without CLONE_PIDFD). For these processes a > > caller can currently not create a pollable pidfd. This is a huge problem > > for Android's low memory killer (LMK) and service managers such as systemd. > > Both are examples of tools that want to make use of pidfds to get reliable > > notification of process exit for non-parents (pidfd polling) and race-free > > signal sending (pidfd_send_signal()). They intend to switch to this API for > > process supervision/management as soon as possible. Having no way to get > > pollable pidfds from PID-only processes is one of the biggest blockers for > > them in adopting this api. With pidfd_open() making it possible to retrieve > > pidfd for PID-based processes we enable them to adopt this api. > > > > In line with Arnd's recent changes to consolidate syscall numbers across > > architectures, I have added the pidfd_open() syscall to all architectures > > at the same time. > > I'm glad it's easier now. > > > arch/alpha/kernel/syscalls/syscall.tbl | 1 + > > arch/arm64/include/asm/unistd32.h | 2 + > > arch/ia64/kernel/syscalls/syscall.tbl | 1 + > > arch/m68k/kernel/syscalls/syscall.tbl | 1 + > > arch/microblaze/kernel/syscalls/syscall.tbl | 1 + > > arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + > > arch/parisc/kernel/syscalls/syscall.tbl | 1 + > > arch/powerpc/kernel/syscalls/syscall.tbl | 1 + > > arch/s390/kernel/syscalls/syscall.tbl | 1 + > > arch/sh/kernel/syscalls/syscall.tbl | 1 + > > arch/sparc/kernel/syscalls/syscall.tbl | 1 + > > arch/x86/entry/syscalls/syscall_32.tbl | 1 + > > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > > arch/xtensa/kernel/syscalls/syscall.tbl | 1 + > > It'd be nice to arrange the system call tables so that we need to > change only one file when adding a new system call. > > [Snip system call wiring] > > > --- a/include/linux/pid.h > > +++ b/include/linux/pid.h > > @@ -67,6 +67,7 @@ struct pid > > extern struct pid init_struct_pid; > > > > extern const struct file_operations pidfd_fops; > > +extern int pidfd_create(struct pid *pid); > > > > static inline struct pid *get_pid(struct pid *pid) > > { > > diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h > > index e2870fe1be5b..989055e0b501 100644 > > --- a/include/linux/syscalls.h > > +++ b/include/linux/syscalls.h > > @@ -929,6 +929,7 @@ asmlinkage long sys_clock_adjtime32(clockid_t which_clock, > > struct old_timex32 __user *tx); > > asmlinkage long sys_syncfs(int fd); > > asmlinkage long sys_setns(int fd, int nstype); > > +asmlinkage long sys_pidfd_open(pid_t pid, unsigned int flags); > > asmlinkage long sys_sendmmsg(int fd, struct mmsghdr __user *msg, > > unsigned int vlen, unsigned flags); > > asmlinkage long sys_process_vm_readv(pid_t pid, > > diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h > > index dee7292e1df6..94a257a93d20 100644 > > --- a/include/uapi/asm-generic/unistd.h > > +++ b/include/uapi/asm-generic/unistd.h > > @@ -832,9 +832,11 @@ __SYSCALL(__NR_io_uring_setup, sys_io_uring_setup) > > __SYSCALL(__NR_io_uring_enter, sys_io_uring_enter) > > #define __NR_io_uring_register 427 > > __SYSCALL(__NR_io_uring_register, sys_io_uring_register) > > +#define __NR_pidfd_open 428 > > +__SYSCALL(__NR_pidfd_open, sys_pidfd_open) > > > > #undef __NR_syscalls > > -#define __NR_syscalls 428 > > +#define __NR_syscalls 429 > > > > /* > > * 32 bit systems traditionally used different > > diff --git a/kernel/fork.c b/kernel/fork.c > > index 737db1828437..980cc1d2b8d4 100644 > > --- a/kernel/fork.c > > +++ b/kernel/fork.c > > @@ -1714,7 +1714,7 @@ const struct file_operations pidfd_fops = { > > * Return: On success, a cloexec pidfd is returned. > > * On error, a negative errno number will be returned. > > */ > > -static int pidfd_create(struct pid *pid) > > +int pidfd_create(struct pid *pid) > > { > > int fd; > > > > diff --git a/kernel/pid.c b/kernel/pid.c > > index 20881598bdfa..237d18d6ecb8 100644 > > --- a/kernel/pid.c > > +++ b/kernel/pid.c > > @@ -38,6 +38,7 @@ > > #include <linux/syscalls.h> > > #include <linux/proc_ns.h> > > #include <linux/proc_fs.h> > > +#include <linux/sched/signal.h> > > #include <linux/sched/task.h> > > #include <linux/idr.h> > > > > @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct pid_namespace *ns) > > return idr_get_next(&ns->idr, &nr); > > } > > > > +/** > > + * pidfd_open() - Open new pid file descriptor. > > + * > > + * @pid: pid for which to retrieve a pidfd > > + * @flags: flags to pass > > + * > > + * This creates a new pid file descriptor with the O_CLOEXEC flag set for > > + * the process identified by @pid. Currently, the process identified by > > + * @pid must be a thread-group leader. This restriction currently exists > > + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot > > + * be used with CLONE_THREAD) and pidfd polling (only supports thread group > > + * leaders). > > + * > > + * Return: On success, a cloexec pidfd is returned. > > + * On error, a negative errno number will be returned. > > + */ > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > +{ > > + int fd, ret; > > + struct pid *p; > > + struct task_struct *tsk; > > + > > + if (flags) > > + return -EINVAL; > > If we support blocking operations on pidfds, we'll want to be able to > put them in non-blocking mode. Does it make sense to accept and ignore > O_NONBLOCK here now? Hm, is there a race condition you see that would prevent you from using fcntl()? If you're ok with using fcntl() I would argue we should hold on tight to every bit we have for flags. > > > + if (pid <= 0) > > + return -EINVAL; > > WDYT of defining pid == 0 to mean "open myself"? I'm torn. It be a nice shortcut of course but pid being 0 is usually an indicator for child processes. So unless the getpid() before pidfd_open() is an issue I'd say let's leave it as is. If you really want the shortcut might -1 be better? > > > + p = find_get_pid(pid); > > + if (!p) > > + return -ESRCH; > > + > > + rcu_read_lock(); > > + tsk = pid_task(p, PIDTYPE_PID); > > + if (!tsk) > > + ret = -ESRCH; > > + else if (unlikely(!thread_group_leader(tsk))) > > + ret = -EINVAL; > > + else > > + ret = 0; > > + rcu_read_unlock(); > > + > > + fd = ret ?: pidfd_create(p); > > + put_pid(p); > > + return fd; > > +}
On Thu, May 16, 2019 at 3:08 PM Christian Brauner <christian@brauner.io> wrote: > On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote: > > On Wed, May 15, 2019 at 3:04 AM Christian Brauner <christian@brauner.io> wrote: > > > > > > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > > > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > > > process that is created via traditional fork()/clone() calls that is only > > > referenced by a PID: [...] > > > +/** > > > + * pidfd_open() - Open new pid file descriptor. > > > + * > > > + * @pid: pid for which to retrieve a pidfd > > > + * @flags: flags to pass > > > + * > > > + * This creates a new pid file descriptor with the O_CLOEXEC flag set for > > > + * the process identified by @pid. Currently, the process identified by > > > + * @pid must be a thread-group leader. This restriction currently exists > > > + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot > > > + * be used with CLONE_THREAD) and pidfd polling (only supports thread group > > > + * leaders). > > > + * > > > + * Return: On success, a cloexec pidfd is returned. > > > + * On error, a negative errno number will be returned. > > > + */ > > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > > +{ [...] > > > + if (pid <= 0) > > > + return -EINVAL; > > > > WDYT of defining pid == 0 to mean "open myself"? > > I'm torn. It be a nice shortcut of course but pid being 0 is usually an > indicator for child processes. So unless the getpid() before > pidfd_open() is an issue I'd say let's leave it as is. If you really > want the shortcut might -1 be better? Joining the bikeshed painting club: Please don't allow either 0 or -1 as shortcut for "self". James Forshaw found an Android security bug a while back (https://bugs.chromium.org/p/project-zero/issues/detail?id=727) that passed a PID to getpidcon(), except that the PID was 0 (placeholder for oneway binder transactions), and then the service thought it was talking to itself. You could pick some other number and provide a #define for that, but I think pidfd_open(getpid(), ...) makes more sense.
On Thu, May 16, 2019 at 04:03:27PM +0200, Jann Horn wrote: > On Thu, May 16, 2019 at 3:08 PM Christian Brauner <christian@brauner.io> wrote: > > On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote: > > > On Wed, May 15, 2019 at 3:04 AM Christian Brauner <christian@brauner.io> wrote: > > > > > > > > This adds the pidfd_open() syscall. It allows a caller to retrieve pollable > > > > pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a > > > > process that is created via traditional fork()/clone() calls that is only > > > > referenced by a PID: > [...] > > > > +/** > > > > + * pidfd_open() - Open new pid file descriptor. > > > > + * > > > > + * @pid: pid for which to retrieve a pidfd > > > > + * @flags: flags to pass > > > > + * > > > > + * This creates a new pid file descriptor with the O_CLOEXEC flag set for > > > > + * the process identified by @pid. Currently, the process identified by > > > > + * @pid must be a thread-group leader. This restriction currently exists > > > > + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot > > > > + * be used with CLONE_THREAD) and pidfd polling (only supports thread group > > > > + * leaders). > > > > + * > > > > + * Return: On success, a cloexec pidfd is returned. > > > > + * On error, a negative errno number will be returned. > > > > + */ > > > > +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) > > > > +{ > [...] > > > > + if (pid <= 0) > > > > + return -EINVAL; > > > > > > WDYT of defining pid == 0 to mean "open myself"? > > > > I'm torn. It be a nice shortcut of course but pid being 0 is usually an > > indicator for child processes. So unless the getpid() before > > pidfd_open() is an issue I'd say let's leave it as is. If you really > > want the shortcut might -1 be better? > > Joining the bikeshed painting club: Please don't allow either 0 or -1 > as shortcut for "self". James Forshaw found an Android security bug a > while back (https://bugs.chromium.org/p/project-zero/issues/detail?id=727) > that passed a PID to getpidcon(), except that the PID was 0 > (placeholder for oneway binder transactions), and then the service > thought it was talking to itself. You could pick some other number and > provide a #define for that, but I think pidfd_open(getpid(), ...) > makes more sense. Yes, I agree. I left it as is for v1, i.e. no shortcut; getpid() should do. Christian
On 2019-05-16, Christian Brauner <christian@brauner.io> wrote: > On Wed, May 15, 2019 at 10:45:06AM -0700, Daniel Colascione wrote: > > On Wed, May 15, 2019 at 3:04 AM Christian Brauner <christian@brauner.io> wrote: > > > + if (pid <= 0) > > > + return -EINVAL; > > > > WDYT of defining pid == 0 to mean "open myself"? > > I'm torn. It be a nice shortcut of course but pid being 0 is usually an > indicator for child processes. So unless the getpid() before > pidfd_open() is an issue I'd say let's leave it as is. If you really > want the shortcut might -1 be better? I'd suggest not using negative numbers, and instead reserving them for PIDTYPE_TGID if we ever want to have that in the future. IMHO, doing pfd = pidfd_open(getpid(), 0); is not the end of the world.
diff --git a/arch/alpha/kernel/syscalls/syscall.tbl b/arch/alpha/kernel/syscalls/syscall.tbl index 165f268beafc..ddc3c93ad7a7 100644 --- a/arch/alpha/kernel/syscalls/syscall.tbl +++ b/arch/alpha/kernel/syscalls/syscall.tbl @@ -467,3 +467,4 @@ 535 common io_uring_setup sys_io_uring_setup 536 common io_uring_enter sys_io_uring_enter 537 common io_uring_register sys_io_uring_register +538 common pidfd_open sys_pidfd_open diff --git a/arch/arm64/include/asm/unistd32.h b/arch/arm64/include/asm/unistd32.h index 23f1a44acada..350e2049b4a9 100644 --- a/arch/arm64/include/asm/unistd32.h +++ b/arch/arm64/include/asm/unistd32.h @@ -874,6 +874,8 @@ __SYSCALL(__NR_io_uring_setup, sys_io_uring_setup) __SYSCALL(__NR_io_uring_enter, sys_io_uring_enter) #define __NR_io_uring_register 427 __SYSCALL(__NR_io_uring_register, sys_io_uring_register) +#define __NR_pidfd_open 428 +__SYSCALL(__NR_pidfd_open, sys_pidfd_open) /* * Please add new compat syscalls above this comment and update diff --git a/arch/ia64/kernel/syscalls/syscall.tbl b/arch/ia64/kernel/syscalls/syscall.tbl index 56e3d0b685e1..7115f6dd347a 100644 --- a/arch/ia64/kernel/syscalls/syscall.tbl +++ b/arch/ia64/kernel/syscalls/syscall.tbl @@ -348,3 +348,4 @@ 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open diff --git a/arch/m68k/kernel/syscalls/syscall.tbl b/arch/m68k/kernel/syscalls/syscall.tbl index df4ec3ec71d1..44bf12b16ffe 100644 --- a/arch/m68k/kernel/syscalls/syscall.tbl +++ b/arch/m68k/kernel/syscalls/syscall.tbl @@ -427,3 +427,4 @@ 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open diff --git a/arch/microblaze/kernel/syscalls/syscall.tbl b/arch/microblaze/kernel/syscalls/syscall.tbl index 4964947732af..0d32e5152dc0 100644 --- a/arch/microblaze/kernel/syscalls/syscall.tbl +++ b/arch/microblaze/kernel/syscalls/syscall.tbl @@ -433,3 +433,4 @@ 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open diff --git a/arch/mips/kernel/syscalls/syscall_n32.tbl b/arch/mips/kernel/syscalls/syscall_n32.tbl index 9392dfe33f97..726e107b3c9f 100644 --- a/arch/mips/kernel/syscalls/syscall_n32.tbl +++ b/arch/mips/kernel/syscalls/syscall_n32.tbl @@ -366,3 +366,4 @@ 425 n32 io_uring_setup sys_io_uring_setup 426 n32 io_uring_enter sys_io_uring_enter 427 n32 io_uring_register sys_io_uring_register +428 n32 pidfd_open sys_pidfd_open diff --git a/arch/parisc/kernel/syscalls/syscall.tbl b/arch/parisc/kernel/syscalls/syscall.tbl index fe8ca623add8..83b46b568d51 100644 --- a/arch/parisc/kernel/syscalls/syscall.tbl +++ b/arch/parisc/kernel/syscalls/syscall.tbl @@ -424,3 +424,4 @@ 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open diff --git a/arch/powerpc/kernel/syscalls/syscall.tbl b/arch/powerpc/kernel/syscalls/syscall.tbl index 00f5a63c8d9a..5294d04d7fa5 100644 --- a/arch/powerpc/kernel/syscalls/syscall.tbl +++ b/arch/powerpc/kernel/syscalls/syscall.tbl @@ -509,3 +509,4 @@ 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open diff --git a/arch/s390/kernel/syscalls/syscall.tbl b/arch/s390/kernel/syscalls/syscall.tbl index 061418f787c3..dcdb838adf49 100644 --- a/arch/s390/kernel/syscalls/syscall.tbl +++ b/arch/s390/kernel/syscalls/syscall.tbl @@ -430,3 +430,4 @@ 425 common io_uring_setup sys_io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open sys_pidfd_open diff --git a/arch/sh/kernel/syscalls/syscall.tbl b/arch/sh/kernel/syscalls/syscall.tbl index 480b057556ee..8e66edfbc521 100644 --- a/arch/sh/kernel/syscalls/syscall.tbl +++ b/arch/sh/kernel/syscalls/syscall.tbl @@ -430,3 +430,4 @@ 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open diff --git a/arch/sparc/kernel/syscalls/syscall.tbl b/arch/sparc/kernel/syscalls/syscall.tbl index a1dd24307b00..d6f3bc686939 100644 --- a/arch/sparc/kernel/syscalls/syscall.tbl +++ b/arch/sparc/kernel/syscalls/syscall.tbl @@ -473,3 +473,4 @@ 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open diff --git a/arch/x86/entry/syscalls/syscall_32.tbl b/arch/x86/entry/syscalls/syscall_32.tbl index 4cd5f982b1e5..1af6b469160a 100644 --- a/arch/x86/entry/syscalls/syscall_32.tbl +++ b/arch/x86/entry/syscalls/syscall_32.tbl @@ -438,3 +438,4 @@ 425 i386 io_uring_setup sys_io_uring_setup __ia32_sys_io_uring_setup 426 i386 io_uring_enter sys_io_uring_enter __ia32_sys_io_uring_enter 427 i386 io_uring_register sys_io_uring_register __ia32_sys_io_uring_register +428 i386 pidfd_open sys_pidfd_open __ia32_sys_pidfd_open diff --git a/arch/x86/entry/syscalls/syscall_64.tbl b/arch/x86/entry/syscalls/syscall_64.tbl index 64ca0d06259a..c18e6ebe3387 100644 --- a/arch/x86/entry/syscalls/syscall_64.tbl +++ b/arch/x86/entry/syscalls/syscall_64.tbl @@ -355,6 +355,7 @@ 425 common io_uring_setup __x64_sys_io_uring_setup 426 common io_uring_enter __x64_sys_io_uring_enter 427 common io_uring_register __x64_sys_io_uring_register +428 common pidfd_open __x64_sys_pidfd_open # # x32-specific system call numbers start at 512 to avoid cache impact diff --git a/arch/xtensa/kernel/syscalls/syscall.tbl b/arch/xtensa/kernel/syscalls/syscall.tbl index 30084eaf8422..21ee795f3003 100644 --- a/arch/xtensa/kernel/syscalls/syscall.tbl +++ b/arch/xtensa/kernel/syscalls/syscall.tbl @@ -398,3 +398,4 @@ 425 common io_uring_setup sys_io_uring_setup 426 common io_uring_enter sys_io_uring_enter 427 common io_uring_register sys_io_uring_register +428 common pidfd_open sys_pidfd_open diff --git a/include/linux/pid.h b/include/linux/pid.h index 3c8ef5a199ca..c938a92eab99 100644 --- a/include/linux/pid.h +++ b/include/linux/pid.h @@ -67,6 +67,7 @@ struct pid extern struct pid init_struct_pid; extern const struct file_operations pidfd_fops; +extern int pidfd_create(struct pid *pid); static inline struct pid *get_pid(struct pid *pid) { diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h index e2870fe1be5b..989055e0b501 100644 --- a/include/linux/syscalls.h +++ b/include/linux/syscalls.h @@ -929,6 +929,7 @@ asmlinkage long sys_clock_adjtime32(clockid_t which_clock, struct old_timex32 __user *tx); asmlinkage long sys_syncfs(int fd); asmlinkage long sys_setns(int fd, int nstype); +asmlinkage long sys_pidfd_open(pid_t pid, unsigned int flags); asmlinkage long sys_sendmmsg(int fd, struct mmsghdr __user *msg, unsigned int vlen, unsigned flags); asmlinkage long sys_process_vm_readv(pid_t pid, diff --git a/include/uapi/asm-generic/unistd.h b/include/uapi/asm-generic/unistd.h index dee7292e1df6..94a257a93d20 100644 --- a/include/uapi/asm-generic/unistd.h +++ b/include/uapi/asm-generic/unistd.h @@ -832,9 +832,11 @@ __SYSCALL(__NR_io_uring_setup, sys_io_uring_setup) __SYSCALL(__NR_io_uring_enter, sys_io_uring_enter) #define __NR_io_uring_register 427 __SYSCALL(__NR_io_uring_register, sys_io_uring_register) +#define __NR_pidfd_open 428 +__SYSCALL(__NR_pidfd_open, sys_pidfd_open) #undef __NR_syscalls -#define __NR_syscalls 428 +#define __NR_syscalls 429 /* * 32 bit systems traditionally used different diff --git a/kernel/fork.c b/kernel/fork.c index 737db1828437..980cc1d2b8d4 100644 --- a/kernel/fork.c +++ b/kernel/fork.c @@ -1714,7 +1714,7 @@ const struct file_operations pidfd_fops = { * Return: On success, a cloexec pidfd is returned. * On error, a negative errno number will be returned. */ -static int pidfd_create(struct pid *pid) +int pidfd_create(struct pid *pid) { int fd; diff --git a/kernel/pid.c b/kernel/pid.c index 20881598bdfa..237d18d6ecb8 100644 --- a/kernel/pid.c +++ b/kernel/pid.c @@ -38,6 +38,7 @@ #include <linux/syscalls.h> #include <linux/proc_ns.h> #include <linux/proc_fs.h> +#include <linux/sched/signal.h> #include <linux/sched/task.h> #include <linux/idr.h> @@ -451,6 +452,53 @@ struct pid *find_ge_pid(int nr, struct pid_namespace *ns) return idr_get_next(&ns->idr, &nr); } +/** + * pidfd_open() - Open new pid file descriptor. + * + * @pid: pid for which to retrieve a pidfd + * @flags: flags to pass + * + * This creates a new pid file descriptor with the O_CLOEXEC flag set for + * the process identified by @pid. Currently, the process identified by + * @pid must be a thread-group leader. This restriction currently exists + * for all aspects of pidfds including pidfd creation (CLONE_PIDFD cannot + * be used with CLONE_THREAD) and pidfd polling (only supports thread group + * leaders). + * + * Return: On success, a cloexec pidfd is returned. + * On error, a negative errno number will be returned. + */ +SYSCALL_DEFINE2(pidfd_open, pid_t, pid, unsigned int, flags) +{ + int fd, ret; + struct pid *p; + struct task_struct *tsk; + + if (flags) + return -EINVAL; + + if (pid <= 0) + return -EINVAL; + + p = find_get_pid(pid); + if (!p) + return -ESRCH; + + rcu_read_lock(); + tsk = pid_task(p, PIDTYPE_PID); + if (!tsk) + ret = -ESRCH; + else if (unlikely(!thread_group_leader(tsk))) + ret = -EINVAL; + else + ret = 0; + rcu_read_unlock(); + + fd = ret ?: pidfd_create(p); + put_pid(p); + return fd; +} + void __init pid_idr_init(void) { /* Verify no one has done anything silly: */
This adds the pidfd_open() syscall. It allows a caller to retrieve pollable pidfds for a process which did not get created via CLONE_PIDFD, i.e. for a process that is created via traditional fork()/clone() calls that is only referenced by a PID: int pidfd = pidfd_open(1234, 0); ret = pidfd_send_signal(pidfd, SIGSTOP, NULL, 0); With the introduction of pidfds through CLONE_PIDFD it is possible to created pidfds at process creation time. However, a lot of processes get created with traditional PID-based calls such as fork() or clone() (without CLONE_PIDFD). For these processes a caller can currently not create a pollable pidfd. This is a huge problem for Android's low memory killer (LMK) and service managers such as systemd. Both are examples of tools that want to make use of pidfds to get reliable notification of process exit for non-parents (pidfd polling) and race-free signal sending (pidfd_send_signal()). They intend to switch to this API for process supervision/management as soon as possible. Having no way to get pollable pidfds from PID-only processes is one of the biggest blockers for them in adopting this api. With pidfd_open() making it possible to retrieve pidfd for PID-based processes we enable them to adopt this api. In line with Arnd's recent changes to consolidate syscall numbers across architectures, I have added the pidfd_open() syscall to all architectures at the same time. Signed-off-by: Christian Brauner <christian@brauner.io> Cc: Arnd Bergmann <arnd@arndb.de> Cc: "Eric W. Biederman" <ebiederm@xmission.com> Cc: Kees Cook <keescook@chromium.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Jann Horn <jannh@google.com> Cc: David Howells <dhowells@redhat.com> Cc: Andy Lutomirsky <luto@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Aleksa Sarai <cyphar@cyphar.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: linux-api@vger.kernel.org --- arch/alpha/kernel/syscalls/syscall.tbl | 1 + arch/arm64/include/asm/unistd32.h | 2 + arch/ia64/kernel/syscalls/syscall.tbl | 1 + arch/m68k/kernel/syscalls/syscall.tbl | 1 + arch/microblaze/kernel/syscalls/syscall.tbl | 1 + arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + arch/parisc/kernel/syscalls/syscall.tbl | 1 + arch/powerpc/kernel/syscalls/syscall.tbl | 1 + arch/s390/kernel/syscalls/syscall.tbl | 1 + arch/sh/kernel/syscalls/syscall.tbl | 1 + arch/sparc/kernel/syscalls/syscall.tbl | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/xtensa/kernel/syscalls/syscall.tbl | 1 + include/linux/pid.h | 1 + include/linux/syscalls.h | 1 + include/uapi/asm-generic/unistd.h | 4 +- kernel/fork.c | 2 +- kernel/pid.c | 48 +++++++++++++++++++++ 19 files changed, 69 insertions(+), 2 deletions(-)