This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v3 03/23] sysdeps/wait: Use waitid if avaliable
- From: ebiederm at xmission dot com (Eric W. Biederman)
- To: Linus Torvalds <torvalds at linux-foundation dot org>
- Cc: Arnd Bergmann <arnd at arndb dot de>, Rich Felker <dalias at libc dot org>, Alistair Francis <alistair dot francis at wdc dot com>, GNU C Library <libc-alpha at sourceware dot org>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Florian Weimer <fweimer at redhat dot com>, Palmer Dabbelt <palmer at sifive dot com>, macro at wdc dot com, Zong Li <zongbox at gmail dot com>, Alistair Francis <alistair23 at gmail dot com>, Andrew Morton <akpm at linux-foundation dot org>, Al Viro <viro at zeniv dot linux dot org dot uk>, Christian Brauner <christian at brauner dot io>, "H. Peter Anvin" <hpa at zytor dot com>
- Date: Sun, 21 Jul 2019 16:40:27 -0500
- Subject: Re: [RFC v3 03/23] sysdeps/wait: Use waitid if avaliable
- References: <cover.1563321715.git.alistair.francis@wdc.com> <2d3359a195633b85e01f83bf536330d72f7bc8aa.1563321715.git.alistair.francis@wdc.com> <20190721040310.GA3283@brightrain.aerifal.cx> <CAK8P3a0bhS_d1SMyLQO_LDNvdgR+MKXmoESxWkrcz22mvjKcuw@mail.gmail.com> <87o91nbn37.fsf@xmission.com> <CAK8P3a3wgavtarKxSYJGL0ME9KRZ8UsUAZw+Y5J8WpG1GQ+=mw@mail.gmail.com> <87muh79yt2.fsf@xmission.com> <CAHk-=wjtGaJFceL+YB6=mTxQCvyNvBTavqgGTm-d5FA9xLQ0Cw@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Sun, Jul 21, 2019 at 8:45 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
>>
>> We either add P_PROCESS_PGID to the kernel's waitid or we add wait4.
>
> Do we actually need a new flag?
>
> Why not just allow people to pass in pid = 0 with the existing P_PGID flag?
>
> Those are the traditional and documented waitpid() semantics. Why
> wouldn't we use those semantics for waitid() too?
>
> And since our current (broken) waitid() returns EINVAL for that case,
> it's even trivial to test for in user space (and fall back on the
> broken racy code in user space - which you have to do anyway).
Our current waitid implementation when serving as waitid is not broken.
What is broken is the waitpid emulation on top of waitid.
The way waitid is defined waitid P_PGID with a pid of 0 means
wait for the process group id of 0. Which in theory and in limited
practice exists. AKA that is the pid and process group of the idle
thread.
Further there is the outstanding question. Should P_PROCESS_PGID refer
to the curent processes process group id at the time of the waitid call,
or should P_PROCESS_PGID refer to the process group id when a child is
found?
It has been suggested elswehere in this conversation that 161550d74c07
("pid: sys_wait... fixes") may have introduced a regression. If so
the current wait4 behavior of capturing the process group at the time
of call is wrong and needs to be fixed.
Not capuring the pid at time time of call is a very different behavior
of P_PROCESS_PGID vs all of the other waitid cases which do have the pid
fixed at the time of the call which further argues a separate flag
because the behavior would be distinctly different.
> Honestly, that seems like the simplest soilution, but also like the
> only sane model. The fact that P_PGID with a zero pid doesn't work
> seems to simply be a bug right now, and keeps waitid() from being a
> proper superset of waitpid().
In the context of waitid it does not look sane. Unlike the other wait
functions waitid does not have any magic ids and by having an idtype
field makes that kind of magic unnecessary. Further it is trivial
to add one line to the architecture independent enumeration and have 0
risk of confusion or of regressing user space.
Eric