Message ID | 20190516135944.7205-1-christian@brauner.io (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | [v1,1/2] pid: add pidfd_open() | expand |
On 05/16, Christian Brauner wrote: > > With the introduction of pidfds through CLONE_PIDFD it is possible to > created pidfds at process creation time. Now I am wondering why do we need CLONE_PIDFD, you can just do pid = fork(); pidfd_open(pid); > +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; > + > + ret = 0; > + rcu_read_lock(); > + /* > + * If this returns non-NULL the pid was used as a thread-group > + * leader. Note, we race with exec here: If it changes the > + * thread-group leader we might return the old leader. > + */ > + tsk = pid_task(p, PIDTYPE_TGID); > + if (!tsk) > + ret = -ESRCH; > + rcu_read_unlock(); > + > + fd = ret ?: pidfd_create(p); > + put_pid(p); > + return fd; > +} Looks correct, feel free to add Reviewed-by: Oleg Nesterov <oleg@redhat.com> But why do we need task_struct *tsk? rcu_read_lock(); if (!pid_task(PIDTYPE_TGID)) ret = -ESRCH; rcu_read_unlock(); and in fact we do not even need rcu_read_lock(), we could do // shut up rcu_dereference_check() rcu_lock_acquire(&rcu_lock_map); if (!pid_task(PIDTYPE_TGID)) ret = -ESRCH; rcu_lock_release(&rcu_lock_map); Well... I won't insist, but the comment about the race with exec looks a bit confusing to me. It is true, but we do not care at all, we are not going to use the task_struct returned by pid_task(). Oleg.
On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote: > On 05/16, Christian Brauner wrote: > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > created pidfds at process creation time. > > Now I am wondering why do we need CLONE_PIDFD, you can just do > > pid = fork(); > pidfd_open(pid); While the race window would be exceptionally short, there is the possibility that the child will die and their pid will be recycled before you do pidfd_open(). CLONE_PIDFD removes the race completely.
Hi Christian, David, On Thu, May 16, 2019 at 4:00 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. > +428 common pidfd_open sys_pidfd_open This number conflicts with "[PATCH 4/4] uapi: Wire up the mount API syscalls on non-x86 arches", which is requested to be included before rc1. Note that none of this is part of linux-next. Gr{oetje,eeting}s, Geert
On Thu, May 16, 2019 at 04:27:00PM +0200, Oleg Nesterov wrote: > On 05/16, Christian Brauner wrote: > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > created pidfds at process creation time. > > Now I am wondering why do we need CLONE_PIDFD, you can just do > > pid = fork(); > pidfd_open(pid); CLONE_PIDFD eliminates the race at the source and let's us avoid two syscalls for the sake of one. That'll obviously matter even more when we enable CLONE_THREAD | CLONE_PIDFD. pidfd_open() is really just a necessity for anyone who does non-parent process management aka LMK or service managers. I also would like to reserve the ability at some point (e.g. with cloneX or sm) to be able to specify specific additional flags at process creation time that modify pidfd behavior. > > > +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; > > + > > + ret = 0; > > + rcu_read_lock(); > > + /* > > + * If this returns non-NULL the pid was used as a thread-group > > + * leader. Note, we race with exec here: If it changes the > > + * thread-group leader we might return the old leader. > > + */ > > + tsk = pid_task(p, PIDTYPE_TGID); > > + if (!tsk) > > + ret = -ESRCH; > > + rcu_read_unlock(); > > + > > + fd = ret ?: pidfd_create(p); > > + put_pid(p); > > + return fd; > > +} > > Looks correct, feel free to add Reviewed-by: Oleg Nesterov <oleg@redhat.com> > > But why do we need task_struct *tsk? > > rcu_read_lock(); > if (!pid_task(PIDTYPE_TGID)) > ret = -ESRCH; > rcu_read_unlock(); Sure, that's simpler. I'll rework and add your Reviewed-by. > > and in fact we do not even need rcu_read_lock(), we could do > > // shut up rcu_dereference_check() > rcu_lock_acquire(&rcu_lock_map); > if (!pid_task(PIDTYPE_TGID)) > ret = -ESRCH; > rcu_lock_release(&rcu_lock_map); > > Well... I won't insist, but the comment about the race with exec looks a bit > confusing to me. It is true, but we do not care at all, we are not going to > use the task_struct returned by pid_task(). Yeah, I can remove it. Thanks! Christian
On Thu, May 16, 2019 at 04:56:08PM +0200, Geert Uytterhoeven wrote: > Hi Christian, David, > > On Thu, May 16, 2019 at 4:00 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. > > > +428 common pidfd_open sys_pidfd_open > > This number conflicts with "[PATCH 4/4] uapi: Wire up the mount API > syscalls on non-x86 arches", which is requested to be included before > rc1. Yep, already spotted this thanks to Arnd! Will change the syscall numbers. Thanks! Christian > > Note that none of this is part of linux-next. > > Gr{oetje,eeting}s, > > Geert > > -- > Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org > > In personal conversations with technical people, I call myself a hacker. But > when I'm talking to journalists I just say "programmer" or something like that. > -- Linus Torvalds
On 05/17, Aleksa Sarai wrote: > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote: > > On 05/16, Christian Brauner wrote: > > > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > > created pidfds at process creation time. > > > > Now I am wondering why do we need CLONE_PIDFD, you can just do > > > > pid = fork(); > > pidfd_open(pid); > > While the race window would be exceptionally short, there is the > possibility that the child will die Yes, > and their pid will be recycled > before you do pidfd_open(). No. Unless the caller's sub-thread does wait() before pidfd_open(), of course. Or unless you do signal(SIGCHILD, SIG_IGN). Oleg.
On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote: > On 05/17, Aleksa Sarai wrote: > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote: > > > On 05/16, Christian Brauner wrote: > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > > > created pidfds at process creation time. > > > > > > Now I am wondering why do we need CLONE_PIDFD, you can just do > > > > > > pid = fork(); > > > pidfd_open(pid); > > > > While the race window would be exceptionally short, there is the > > possibility that the child will die > > Yes, > > > and their pid will be recycled > > before you do pidfd_open(). > > No. > > Unless the caller's sub-thread does wait() before pidfd_open(), of course. > Or unless you do signal(SIGCHILD, SIG_IGN). What about CLONE_PARENT?
On 05/17, Aleksa Sarai wrote: > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote: > > On 05/17, Aleksa Sarai wrote: > > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote: > > > > On 05/16, Christian Brauner wrote: > > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > > > > created pidfds at process creation time. > > > > > > > > Now I am wondering why do we need CLONE_PIDFD, you can just do > > > > > > > > pid = fork(); > > > > pidfd_open(pid); > > > > > > While the race window would be exceptionally short, there is the > > > possibility that the child will die > > > > Yes, > > > > > and their pid will be recycled > > > before you do pidfd_open(). > > > > No. > > > > Unless the caller's sub-thread does wait() before pidfd_open(), of course. > > Or unless you do signal(SIGCHILD, SIG_IGN). > > What about CLONE_PARENT? I should have mentioned CLONE_PARENT ;) Of course in this case the child can be reaped before pidfd_open(). But how often do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially eliminate/detect this race if you really need this. Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea. But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily use pidfd_open(), but not CLONE_PIDFD. Oleg.
On Thu, May 16, 2019 at 05:22:53PM +0200, Oleg Nesterov wrote: > On 05/17, Aleksa Sarai wrote: > > > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote: > > > On 05/17, Aleksa Sarai wrote: > > > > On 2019-05-16, Oleg Nesterov <oleg@redhat.com> wrote: > > > > > On 05/16, Christian Brauner wrote: > > > > > > With the introduction of pidfds through CLONE_PIDFD it is possible to > > > > > > created pidfds at process creation time. > > > > > > > > > > Now I am wondering why do we need CLONE_PIDFD, you can just do > > > > > > > > > > pid = fork(); > > > > > pidfd_open(pid); > > > > > > > > While the race window would be exceptionally short, there is the > > > > possibility that the child will die > > > > > > Yes, > > > > > > > and their pid will be recycled > > > > before you do pidfd_open(). > > > > > > No. > > > > > > Unless the caller's sub-thread does wait() before pidfd_open(), of course. > > > Or unless you do signal(SIGCHILD, SIG_IGN). > > > > What about CLONE_PARENT? > > I should have mentioned CLONE_PARENT ;) > > Of course in this case the child can be reaped before pidfd_open(). But how often > do you or other people use clone(CLONE_PARENT) ? not to mention you can trivially > eliminate/detect this race if you really need this. > > Don't get me wrong, I am not trying to say that CLONE_PIDFD is a bad idea. > > But to me pidfd_open() is much more useful. Say, as a perl programmer I can easily > use pidfd_open(), but not CLONE_PIDFD. Right, but for a libc, service- or container manager CLONE_PIDFD is much nicer when spawning processes quickly. :) I think both are very good to have. Thanks, Oleg. As always super helpful reviews. :) Christian
Hi Christian, For next revision, could you also CC surenb@google.com as well? He is also working on the low memory killer. And also suggest CC to kernel-team@android.com. And mentioned some comments below, thanks. On Thu, May 16, 2019 at 03:59:42PM +0200, Christian Brauner wrote: [snip] > diff --git a/kernel/pid.c b/kernel/pid.c > index 20881598bdfa..4afca3d6dcb8 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,55 @@ 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; > + > + ret = 0; > + rcu_read_lock(); > + /* > + * If this returns non-NULL the pid was used as a thread-group > + * leader. Note, we race with exec here: If it changes the > + * thread-group leader we might return the old leader. > + */ > + tsk = pid_task(p, PIDTYPE_TGID); Just trying to understand the comment here. The issue is that we might either return the new leader, or the old leader depending on the overlap with concurrent de_thread right? In either case, we don't care though. I suggest to remove the "Note..." part of the comment since it doesn't seem the race is relevant here unless we are doing something else with tsk in the function, but if you want to keep it that's also fine. Comment text should probably should be 'return the new leader' though. > + if (!tsk) > + ret = -ESRCH; Perhaps -EINVAL? AFAICS, this can only happen if a CLONE_THREAD pid was passed as argument to pidfd_open which is invalid. But let me know what you had in mind.. thanks, - Joel > + 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: */ > -- > 2.21.0 >
On Sat, May 18, 2019 at 05:48:03AM -0400, Joel Fernandes wrote: > Hi Christian, > > For next revision, could you also CC surenb@google.com as well? He is also > working on the low memory killer. And also suggest CC to > kernel-team@android.com. And mentioned some comments below, thanks. Yip, totally. Just added them both to my Cc list. :) (I saw you added Suren manually. I added the Android kernel team now too.) > > On Thu, May 16, 2019 at 03:59:42PM +0200, Christian Brauner wrote: > [snip] > > diff --git a/kernel/pid.c b/kernel/pid.c > > index 20881598bdfa..4afca3d6dcb8 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,55 @@ 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; > > + > > + ret = 0; > > + rcu_read_lock(); > > + /* > > + * If this returns non-NULL the pid was used as a thread-group > > + * leader. Note, we race with exec here: If it changes the > > + * thread-group leader we might return the old leader. > > + */ > > + tsk = pid_task(p, PIDTYPE_TGID); > > Just trying to understand the comment here. The issue is that we might either > return the new leader, or the old leader depending on the overlap with > concurrent de_thread right? In either case, we don't care though. > > I suggest to remove the "Note..." part of the comment since it doesn't seem the > race is relevant here unless we are doing something else with tsk in the > function, but if you want to keep it that's also fine. Comment text should > probably should be 'return the new leader' though. Nah, I actually removed the comment already independently (cf. see [1]). [1]: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/commit/?h=pidfd_open&id=dcfc98c2d957bf3ac14b06414cb2cf4c673fc297 > > > + if (!tsk) > > + ret = -ESRCH; > > Perhaps -EINVAL? AFAICS, this can only happen if a CLONE_THREAD pid was > passed as argument to pidfd_open which is invalid. But let me know what you > had in mind.. Hm, from the kernel's perspective ESRCH is correct but I guess EINVAL is nicer for userspace. So I don't have objections to using EINVAL. My first version did too I think. Thanks! Christian
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/arm/tools/syscall.tbl b/arch/arm/tools/syscall.tbl index 0393917eaa57..fc41fb34a636 100644 --- a/arch/arm/tools/syscall.tbl +++ b/arch/arm/tools/syscall.tbl @@ -441,3 +441,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/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..4afca3d6dcb8 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,55 @@ 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; + + ret = 0; + rcu_read_lock(); + /* + * If this returns non-NULL the pid was used as a thread-group + * leader. Note, we race with exec here: If it changes the + * thread-group leader we might return the old leader. + */ + tsk = pid_task(p, PIDTYPE_TGID); + if (!tsk) + ret = -ESRCH; + 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: */