Sixth draft of the Y2038 design document

Sixth draft of the Y2038 design document

[Albert ARIBAUD]

Hi all,

I have produced a sixth draft of what will eventually become the Y2038
design document:

https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146

Relative to the previous draft:

 * Precisions re padding in struct timespec was added.

 * Better separation of APIs and implementations; notably, developed
   the distinction between API types and implementation types.

 * Cleaned up API tables (e.g., removed argument names and left types
   only).

 * Also developed on implementation vs kernel types (e.g., struct
   timespec conversion between GLIB padded versions and kernel non-
   padded versions.

As always, comments welcome.

Cordialement,
Albert ARIBAUD
3ADEV

Y2038: seventh draft of the design document and 1st WIP branch

[Albert ARIBAUD]

Hi all,

I have produced a seventh draft of the Y2038 design document:

https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=153

Relative to the previous draft (to which there were no comments
apparently):

 * Some precisions were added regarding implementation types

 * The location of a WIP implementation branch is provided  

As always, comments welcome on the document.

Regarding the branch, should I post it here as an [RFC] patch series?
Right now, I'm thinking it is not complete enough for a usual RFC,
but I need feedback to know what is in the right direction and what is
not.

For the moment, the branch only targets ARM, not all APIs are
implemented, and some (the stat family) are WIP because at the moment
there are no kernel patches available to provide Y2038-proof stat
syscalls, so the impelmentations skip the "try the 64-bit-time
syscalls if available" part and skip straight to the "fallback to
32-bit, non-Y2038-proof, syscalls" part.

Note: I have created a framework to test the branch, available at
https://github.com/3adev/y2038. It builds tests for an ARM
architecture and runs them in a QEMU ARM system containing a
Y2038-patched kernel, the Y2038 GLIBC WIP branch, a busybox-based
minimal root fs and system, and ad hoc test applications (one built
with -DTIME_BITS=64, one without, for comparison). This too is WIP, as
it progresses alongside the GLIBC branch.

Thanks in advance for your feedback.

Cordialement,
Albert ARIBAUD
3ADEV

Re: Sixth draft of the Y2038 design document

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 865 bytes --]

Hi,

On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
> Hi all,
> 
> I have produced a sixth draft of what will eventually become the Y2038
> design document:
> 
> https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
> 
> Relative to the previous draft:
> 
>  * Precisions re padding in struct timespec was added.
> 
>  * Better separation of APIs and implementations; notably, developed
>    the distinction between API types and implementation types.
> 
>  * Cleaned up API tables (e.g., removed argument names and left types
>    only).
> 
>  * Also developed on implementation vs kernel types (e.g., struct
>    timespec conversion between GLIB padded versions and kernel non-
>    padded versions.
> 
> As always, comments welcome.

Is there any rationale for marking wait4 as an obsolete API?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: Sixth draft of the Y2038 design document

[Arnd Bergmann]

On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
>
> Hi,
>
> On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
> > Hi all,
> >
> > I have produced a sixth draft of what will eventually become the Y2038
> > design document:
> >
> > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
> >
> > Relative to the previous draft:
> >
> >  * Precisions re padding in struct timespec was added.
> >
> >  * Better separation of APIs and implementations; notably, developed
> >    the distinction between API types and implementation types.
> >
> >  * Cleaned up API tables (e.g., removed argument names and left types
> >    only).
> >
> >  * Also developed on implementation vs kernel types (e.g., struct
> >    timespec conversion between GLIB padded versions and kernel non-
> >    padded versions.
> >
> > As always, comments welcome.
>
> Is there any rationale for marking wait4 as an obsolete API?

In the *kernel* syscall API, wait4(2) is obsoleted by waitid(2), which is
a strict superset of its functionality.

In the libc API, this is different, as wait4() does not have a replacement
that is exposed to user space directly. I expect glibc to implement
wait4() on top of the kernel's waitid().

There has not been a final decision on which variant of waitid() that would
be. The easiest option would be to not change it at all: new architectures
(rv32, csky, nanomips/p32, ...) would keep exposing the traditional
waitid() in Linux, with its 32-bit time_t based rusage structure, but drop the
wait4(). glibc then has to convert between the kernel's rusage and the
user space rusage indefinitely.

Alternatively, we can create a new version like waitid2() that uses
64-bit time_t in some form, either the exact same rusage that we
use on 64-bit architectures and x32, or using a new set of arguments
to include further improvements.

        Arnd

Re: extending wait4(2) or waitid(2) linux syscall

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
[...]
> > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
> > Is there any rationale for marking wait4 as an obsolete API?
> 
> In the *kernel* syscall API, wait4(2) is obsoleted by waitid(2), which is
> a strict superset of its functionality.
> 
> In the libc API, this is different, as wait4() does not have a replacement
> that is exposed to user space directly. I expect glibc to implement
> wait4() on top of the kernel's waitid().
> 
> There has not been a final decision on which variant of waitid() that would
> be. The easiest option would be to not change it at all: new architectures
> (rv32, csky, nanomips/p32, ...) would keep exposing the traditional
> waitid() in Linux, with its 32-bit time_t based rusage structure, but drop the
> wait4(). glibc then has to convert between the kernel's rusage and the
> user space rusage indefinitely.
> 
> Alternatively, we can create a new version like waitid2() that uses
> 64-bit time_t in some form, either the exact same rusage that we
> use on 64-bit architectures and x32, or using a new set of arguments
> to include further improvements.

In strace, we have two use cases that require an extended version
of wait4(2) or waitid(2) syscall.  From your response I understand that
you'd recommend extending waitid(2) rather than wait4(2), is it correct?

These two use cases were mentioned in my talk yesterday at LPC 2018,
here is a brief summary.

1. strace needs a race-free invocation of wait4(2) or waitid(2)
with a different signal mask, this cannot be achieved without
an extended version of syscall, similar to pselect6(2) extension
over select(2) and ppoll(2) extension over poll(2).

Signal mask specification in linux requires two parameters:
"const sigset_t *sigmask" and "size_t sigsetsize".
Creating pwait6(2) as an extension of wait4(2) with two arguments
is straightforward.
Creating pwaitid(2) as an extension of waitid(2) that already has 5
arguments would require an indirection similar to pselect6(2).

2. The time precision provided by struct rusage returned by wait4(2) and
waitid(2) is too low for syscall time counting (strace -c) nowadays, this
can be observing by running in a row a simple command like "strace -c pwd".

The fix is to return a more appropriate structure than struct rusage
by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
struct timeval is replaced with struct timespec or even struct timespec64.


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: extending wait4(2) or waitid(2) linux syscall

[hpa]

On November 15, 2018 7:30:11 AM PST, "Dmitry V. Levin" <ldv@altlinux.org> wrote:
>On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
>> On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
>> > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
>[...]
>> > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
>> > Is there any rationale for marking wait4 as an obsolete API?
>> 
>> In the *kernel* syscall API, wait4(2) is obsoleted by waitid(2),
>which is
>> a strict superset of its functionality.
>> 
>> In the libc API, this is different, as wait4() does not have a
>replacement
>> that is exposed to user space directly. I expect glibc to implement
>> wait4() on top of the kernel's waitid().
>> 
>> There has not been a final decision on which variant of waitid() that
>would
>> be. The easiest option would be to not change it at all: new
>architectures
>> (rv32, csky, nanomips/p32, ...) would keep exposing the traditional
>> waitid() in Linux, with its 32-bit time_t based rusage structure, but
>drop the
>> wait4(). glibc then has to convert between the kernel's rusage and
>the
>> user space rusage indefinitely.
>> 
>> Alternatively, we can create a new version like waitid2() that uses
>> 64-bit time_t in some form, either the exact same rusage that we
>> use on 64-bit architectures and x32, or using a new set of arguments
>> to include further improvements.
>
>In strace, we have two use cases that require an extended version
>of wait4(2) or waitid(2) syscall.  From your response I understand that
>you'd recommend extending waitid(2) rather than wait4(2), is it
>correct?
>
>These two use cases were mentioned in my talk yesterday at LPC 2018,
>here is a brief summary.
>
>1. strace needs a race-free invocation of wait4(2) or waitid(2)
>with a different signal mask, this cannot be achieved without
>an extended version of syscall, similar to pselect6(2) extension
>over select(2) and ppoll(2) extension over poll(2).
>
>Signal mask specification in linux requires two parameters:
>"const sigset_t *sigmask" and "size_t sigsetsize".
>Creating pwait6(2) as an extension of wait4(2) with two arguments
>is straightforward.
>Creating pwaitid(2) as an extension of waitid(2) that already has 5
>arguments would require an indirection similar to pselect6(2).
>
>2. The time precision provided by struct rusage returned by wait4(2)
>and
>waitid(2) is too low for syscall time counting (strace -c) nowadays,
>this
>can be observing by running in a row a simple command like "strace -c
>pwd".
>
>The fix is to return a more appropriate structure than struct rusage
>by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
>struct timeval is replaced with struct timespec or even struct
>timespec64.

Arnd: w.r.t. our previous discussion, this would seem to justify going to timespec(64) for these kind of cases.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: extending wait4(2) or waitid(2) linux syscall

[Arnd Bergmann]

On Thu, Nov 15, 2018 at 7:38 AM <hpa@zytor.com> wrote:
> On November 15, 2018 7:30:11 AM PST, "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> >On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> >> On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> >> > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:

> >2. The time precision provided by struct rusage returned by wait4(2)
> >and waitid(2) is too low for syscall time counting (strace -c) nowadays,
> >this can be observing by running in a row a simple command like "strace -c
> >pwd".
> >
> >The fix is to return a more appropriate structure than struct rusage
> >by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
> >struct timeval is replaced with struct timespec or even struct
> >timespec64.
>
> Arnd: w.r.t. our previous discussion, this would seem to justify going to timespec(64) for these kind of cases.

Ok, and I assume we want the same layout for getrusage(2) then, right?

        Arnd

Re: extending wait4(2) or waitid(2) linux syscall

[Florian Weimer]

* Arnd Bergmann:

> On Thu, Nov 15, 2018 at 7:38 AM <hpa@zytor.com> wrote:
>> On November 15, 2018 7:30:11 AM PST, "Dmitry V. Levin" <ldv@altlinux.org> wrote:
>> >On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
>> >> On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
>> >> > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
>
>> >2. The time precision provided by struct rusage returned by wait4(2)
>> >and waitid(2) is too low for syscall time counting (strace -c) nowadays,
>> >this can be observing by running in a row a simple command like "strace -c
>> >pwd".
>> >
>> >The fix is to return a more appropriate structure than struct rusage
>> >by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
>> >struct timeval is replaced with struct timespec or even struct
>> >timespec64.
>>
>> Arnd: w.r.t. our previous discussion, this would seem to justify going to timespec(64) for these kind of cases.
>
> Ok, and I assume we want the same layout for getrusage(2) then, right?

Or introduce something that covers FreeBSD's wait6 functionality as well
(resource usage by subprocesses of the subprocess).

Thanks,
Florian

Re: extending wait4(2) or waitid(2) linux syscall

[Arnd Bergmann]

On Fri, Nov 16, 2018 at 2:27 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > On Thu, Nov 15, 2018 at 7:38 AM <hpa@zytor.com> wrote:
> >> On November 15, 2018 7:30:11 AM PST, "Dmitry V. Levin" <ldv@altlinux.org> wrote:
> >> >On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> >> >> On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> >> >> > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
> >
> >> >2. The time precision provided by struct rusage returned by wait4(2)
> >> >and waitid(2) is too low for syscall time counting (strace -c) nowadays,
> >> >this can be observing by running in a row a simple command like "strace -c
> >> >pwd".
> >> >
> >> >The fix is to return a more appropriate structure than struct rusage
> >> >by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
> >> >struct timeval is replaced with struct timespec or even struct
> >> >timespec64.
> >>
> >> Arnd: w.r.t. our previous discussion, this would seem to justify going to timespec(64) for these kind of cases.
> >
> > Ok, and I assume we want the same layout for getrusage(2) then, right?
>
> Or introduce something that covers FreeBSD's wait6 functionality as well
> (resource usage by subprocesses of the subprocess).

Ok, so combining that with the request for a signal mask, we'd want
something like

int wait9(idtype_t idtype, id_t id, siginfo_t *infop, int options,
       /* waitid subset */
           int *status, struct rusage64 *self, struct rusage64
*children,  /* wait4, wait6, time64 */
           const sigset_t *sigmask, size_t sigsetsize);
       /* suggested by Dmitry */

which I think could over all use cases mentioned in this thread, but
already has nine arguments instead of the allowed six, so it can't
be the signature of the system call entry.

We can get that down to six arguments in the familiar ways:
- like Linux waitid, wait4-style status can be computed from infop
- like wait6, self and children can be in one pointer
- like io_pgetevents, sigmask and sigsetsize can be an indirect struct

int waitid6(idtype_t idtype, id_t id, siginfo_t *infop, int options,
          struct __wrusage64 *wrusage, struct __wait_sigset *sigset);

Alternatively, we could combine even more arguments into a single
structure if inputs, in various ways.

        Arnd

Re: extending wait4(2) or waitid(2) linux syscall

[Paul Eggert]

On 11/16/18 7:17 AM, Arnd Bergmann wrote:
> we'd want something like
>
> int wait9(...)

We're getting uncomfortably close to the Perlis limit.

"If you have a procedure with 10 parameters, you probably missed some."

Perlis AJ. Epigrams on programming. SIGPLAN Notices. 1982:17(9):7-13. 
https://dx.doi.org/10.1145/947955.1083808 
http://pu.inf.uni-tuebingen.de/users/klaeren/epigrams.html

Re: extending wait4(2) or waitid(2) linux syscall

[hpa]

On November 15, 2018 11:14:21 PM PST, Arnd Bergmann <arnd@arndb.de> wrote:
>On Thu, Nov 15, 2018 at 7:38 AM <hpa@zytor.com> wrote:
>> On November 15, 2018 7:30:11 AM PST, "Dmitry V. Levin"
><ldv@altlinux.org> wrote:
>> >On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
>> >> On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
>> >> > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
>
>> >2. The time precision provided by struct rusage returned by wait4(2)
>> >and waitid(2) is too low for syscall time counting (strace -c)
>nowadays,
>> >this can be observing by running in a row a simple command like
>"strace -c
>> >pwd".
>> >
>> >The fix is to return a more appropriate structure than struct rusage
>> >by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
>> >struct timeval is replaced with struct timespec or even struct
>> >timespec64.
>>
>> Arnd: w.r.t. our previous discussion, this would seem to justify
>going to timespec(64) for these kind of cases.
>
>Ok, and I assume we want the same layout for getrusage(2) then, right?
>
>        Arnd

Right 
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: extending wait4(2) or waitid(2) linux syscall

[hpa]

On November 15, 2018 11:14:21 PM PST, Arnd Bergmann <arnd@arndb.de> wrote:
>On Thu, Nov 15, 2018 at 7:38 AM <hpa@zytor.com> wrote:
>> On November 15, 2018 7:30:11 AM PST, "Dmitry V. Levin"
><ldv@altlinux.org> wrote:
>> >On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
>> >> On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
>> >> > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
>
>> >2. The time precision provided by struct rusage returned by wait4(2)
>> >and waitid(2) is too low for syscall time counting (strace -c)
>nowadays,
>> >this can be observing by running in a row a simple command like
>"strace -c
>> >pwd".
>> >
>> >The fix is to return a more appropriate structure than struct rusage
>> >by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
>> >struct timeval is replaced with struct timespec or even struct
>> >timespec64.
>>
>> Arnd: w.r.t. our previous discussion, this would seem to justify
>going to timespec(64) for these kind of cases.
>
>Ok, and I assume we want the same layout for getrusage(2) then, right?
>
>        Arnd

Note that now we have to add one system calls for 64-but platforms. Thus, the right way to do that is to add those new system calls (e.g. waitidns()), and *only* provide those for 32-bit Y2038.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: extending wait4(2) or waitid(2) linux syscall

[Arnd Bergmann]

On Thu, Nov 15, 2018 at 7:30 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
>
> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
> [...]
> > > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
> > > Is there any rationale for marking wait4 as an obsolete API?
> >
> > In the *kernel* syscall API, wait4(2) is obsoleted by waitid(2), which is
> > a strict superset of its functionality.
> >
> > In the libc API, this is different, as wait4() does not have a replacement
> > that is exposed to user space directly. I expect glibc to implement
> > wait4() on top of the kernel's waitid().
> >
> > There has not been a final decision on which variant of waitid() that would
> > be. The easiest option would be to not change it at all: new architectures
> > (rv32, csky, nanomips/p32, ...) would keep exposing the traditional
> > waitid() in Linux, with its 32-bit time_t based rusage structure, but drop the
> > wait4(). glibc then has to convert between the kernel's rusage and the
> > user space rusage indefinitely.
> >
> > Alternatively, we can create a new version like waitid2() that uses
> > 64-bit time_t in some form, either the exact same rusage that we
> > use on 64-bit architectures and x32, or using a new set of arguments
> > to include further improvements.
>
> In strace, we have two use cases that require an extended version
> of wait4(2) or waitid(2) syscall.  From your response I understand that
> you'd recommend extending waitid(2) rather than wait4(2), is it correct?

Correct. It's already a superset, so a new waitid2(2) or wait5(2) should be
an extension of waitid(2) in order to provide backwards compatibility to the
other ones (along with wait() and waitpid()).

> These two use cases were mentioned in my talk yesterday at LPC 2018,
> here is a brief summary.
>
> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
> with a different signal mask, this cannot be achieved without
> an extended version of syscall, similar to pselect6(2) extension
> over select(2) and ppoll(2) extension over poll(2).
>
> Signal mask specification in linux requires two parameters:
> "const sigset_t *sigmask" and "size_t sigsetsize".
> Creating pwait6(2) as an extension of wait4(2) with two arguments
> is straightforward.
> Creating pwaitid(2) as an extension of waitid(2) that already has 5
> arguments would require an indirection similar to pselect6(2).

Right, that indirection is not ideal, but I suspect it's better
than the alternatives.

> 2. The time precision provided by struct rusage returned by wait4(2) and
> waitid(2) is too low for syscall time counting (strace -c) nowadays, this
> can be observing by running in a row a simple command like "strace -c pwd".
>
> The fix is to return a more appropriate structure than struct rusage
> by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
> struct timeval is replaced with struct timespec or even struct timespec64.

It definitely has to be a 64-bit based structure, the question is which one.
My preferred solution would be to interpret the timestamps as 'struct
__kernel_timespec', which has a 64-bit seconds and 64-bit nanoseconds.
I'd also use a structure that is the same between 32-bit and 64-bit
kernels here, using '__s64' members instead of '__kernel_long_t' or 'long'
for the rest. It is then up to the C library to convert it into whichever
structure they want to expose to user space for the normal wait4().

        Arnd

Re: extending wait4(2) or waitid(2) linux syscall

[Dave Martin]

On Thu, Nov 15, 2018 at 06:30:11PM +0300, Dmitry V. Levin wrote:
> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
> [...]
> > > > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
> > > Is there any rationale for marking wait4 as an obsolete API?
> > 
> > In the *kernel* syscall API, wait4(2) is obsoleted by waitid(2), which is
> > a strict superset of its functionality.
> > 
> > In the libc API, this is different, as wait4() does not have a replacement
> > that is exposed to user space directly. I expect glibc to implement
> > wait4() on top of the kernel's waitid().
> > 
> > There has not been a final decision on which variant of waitid() that would
> > be. The easiest option would be to not change it at all: new architectures
> > (rv32, csky, nanomips/p32, ...) would keep exposing the traditional
> > waitid() in Linux, with its 32-bit time_t based rusage structure, but drop the
> > wait4(). glibc then has to convert between the kernel's rusage and the
> > user space rusage indefinitely.
> > 
> > Alternatively, we can create a new version like waitid2() that uses
> > 64-bit time_t in some form, either the exact same rusage that we
> > use on 64-bit architectures and x32, or using a new set of arguments
> > to include further improvements.
> 
> In strace, we have two use cases that require an extended version
> of wait4(2) or waitid(2) syscall.  From your response I understand that
> you'd recommend extending waitid(2) rather than wait4(2), is it correct?
> 
> These two use cases were mentioned in my talk yesterday at LPC 2018,
> here is a brief summary.
> 
> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
> with a different signal mask, this cannot be achieved without
> an extended version of syscall, similar to pselect6(2) extension
> over select(2) and ppoll(2) extension over poll(2).
> 
> Signal mask specification in linux requires two parameters:
> "const sigset_t *sigmask" and "size_t sigsetsize".
> Creating pwait6(2) as an extension of wait4(2) with two arguments
> is straightforward.
> Creating pwaitid(2) as an extension of waitid(2) that already has 5
> arguments would require an indirection similar to pselect6(2).
> 
> 2. The time precision provided by struct rusage returned by wait4(2) and
> waitid(2) is too low for syscall time counting (strace -c) nowadays, this
> can be observing by running in a row a simple command like "strace -c pwd".
> 
> The fix is to return a more appropriate structure than struct rusage
> by the new pwait6(2)/pwaitid(2) syscall mentioned above, where
> struct timeval is replaced with struct timespec or even struct timespec64.

I didn't attend LPC so apologies if I'm missing some background here,
but:

The traditional way would be install a handler for SIGCHLD and
do a sigsuspend()/pselect()/ppoll().  Then when the suspend() returns,
you pump the status of any children with wait*(..., WNOHANG).

Does that not work for you for some reason?

Adding more and more "wait for some stuff" syscalls for every possible
definition of "some stuff" is a slippery slope... IMHO we have way too
many of those already.


One way to improve struct rusage would be to add a new wait flag (say,
WFANCY_RUSAGE) to the existing wait calls to indicate use of a different
struct in place of struct rusage.  It's not clear to me why a brand new
syscall is essential, though obviously that's an option.

Cheers
---Dave

Re: extending wait4(2) or waitid(2) linux syscall

[Florian Weimer]

* Dave Martin:

> The traditional way would be install a handler for SIGCHLD and
> do a sigsuspend()/pselect()/ppoll().  Then when the suspend() returns,
> you pump the status of any children with wait*(..., WNOHANG).
>
> Does that not work for you for some reason?

Changing signal handlers is not what a library should do because they
are process-global (not even thread-specific).

Thanks,
Florian

Re: extending wait4(2) or waitid(2) linux syscall

[Dave Martin]

On Fri, Nov 16, 2018 at 02:40:49PM +0100, Florian Weimer wrote:
> * Dave Martin:
> 
> > The traditional way would be install a handler for SIGCHLD and
> > do a sigsuspend()/pselect()/ppoll().  Then when the suspend() returns,
> > you pump the status of any children with wait*(..., WNOHANG).
> >
> > Does that not work for you for some reason?
> 
> Changing signal handlers is not what a library should do because they
> are process-global (not even thread-specific).

True, though this is a problem with global resources too.
I guess I need to go and read the slides to understand the broader
context here.  (Is strace a library?)

Cheers
---Dave

Re: extending wait4(2) or waitid(2) linux syscall

[Arnd Bergmann]

On Thu, Nov 15, 2018 at 7:30 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
>
> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
> with a different signal mask, this cannot be achieved without
> an extended version of syscall, similar to pselect6(2) extension
> over select(2) and ppoll(2) extension over poll(2).
>
> Signal mask specification in linux requires two parameters:
> "const sigset_t *sigmask" and "size_t sigsetsize".
> Creating pwait6(2) as an extension of wait4(2) with two arguments
> is straightforward.
> Creating pwaitid(2) as an extension of waitid(2) that already has 5
> arguments would require an indirection similar to pselect6(2).

Getting back to this point: you could also do the same thing with
the CLONE_FD approach from Josh Triplett[1] or Casey Dahlin's
older waitfd() syscall, correct?

Neither of them got merged, bu t we could revisit the ideas if they
make it easier to solve your problem by calling ppoll().

        Arnd

[1] https://lwn.net/Articles/638613/
[2] https://lore.kernel.org/lkml/49639EB8.40204@redhat.com/

Re: extending wait4(2) or waitid(2) linux syscall

[Florian Weimer]

* Arnd Bergmann:

> On Thu, Nov 15, 2018 at 7:30 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
>> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
>> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
>> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
>>
>> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
>> with a different signal mask, this cannot be achieved without
>> an extended version of syscall, similar to pselect6(2) extension
>> over select(2) and ppoll(2) extension over poll(2).
>>
>> Signal mask specification in linux requires two parameters:
>> "const sigset_t *sigmask" and "size_t sigsetsize".
>> Creating pwait6(2) as an extension of wait4(2) with two arguments
>> is straightforward.
>> Creating pwaitid(2) as an extension of waitid(2) that already has 5
>> arguments would require an indirection similar to pselect6(2).
>
> Getting back to this point: you could also do the same thing with
> the CLONE_FD approach from Josh Triplett[1] or Casey Dahlin's
> older waitfd() syscall, correct?

A descriptor-based solution would not be useful to glibc because
applications assume that glibc does not (persistently) open any file
descriptors behind t heir back.

Thanks,
Florian

Re: extending wait4(2) or waitid(2) linux syscall

[Arnd Bergmann]

On Mon, Nov 26, 2018 at 4:18 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Arnd Bergmann:
>
> > On Thu, Nov 15, 2018 at 7:30 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
> >> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> >> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> >> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
> >>
> >> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
> >> with a different signal mask, this cannot be achieved without
> >> an extended version of syscall, similar to pselect6(2) extension
> >> over select(2) and ppoll(2) extension over poll(2).
> >>
> >> Signal mask specification in linux requires two parameters:
> >> "const sigset_t *sigmask" and "size_t sigsetsize".
> >> Creating pwait6(2) as an extension of wait4(2) with two arguments
> >> is straightforward.
> >> Creating pwaitid(2) as an extension of waitid(2) that already has 5
> >> arguments would require an indirection similar to pselect6(2).
> >
> > Getting back to this point: you could also do the same thing with
> > the CLONE_FD approach from Josh Triplett[1] or Casey Dahlin's
> > older waitfd() syscall, correct?
>
> A descriptor-based solution would not be useful to glibc because
> applications assume that glibc does not (persistently) open any file
> descriptors behind t heir back.

Right, makes sense. What about a temporary file descriptor as discussed
in the recent procfd() mail thread then? Would that work?

/* for illustration, needs error handling and more features */
int pwait(pid_t id, siginfo_t *infop)
{
      char waitfd_file[MAX_PROCFD_LEN];
      struct pollfd pfd[1] = { {.events = POLLIN }};

      snprintf(waitfd_file, MAX_PROCFD_LEN, "/proc/%d/wait", pid);
      pfd.fd = open(waitfd_file,  O_RDONLY);
      ppoll(&pfd, 1, NULL, sigmask);
      read(fd, infop, sizeof(*infop));
      close(fd);

     return 0;
}

       Arnd

Re: extending wait4(2) or waitid(2) linux syscall

[Daniel Colascione]

On Mon, Nov 26, 2018 at 9:15 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Nov 26, 2018 at 4:18 PM Florian Weimer <fweimer@redhat.com> wrote:
> >
> > * Arnd Bergmann:
> >
> > > On Thu, Nov 15, 2018 at 7:30 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
> > >> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
> > >> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
> > >> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
> > >>
> > >> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
> > >> with a different signal mask, this cannot be achieved without
> > >> an extended version of syscall, similar to pselect6(2) extension
> > >> over select(2) and ppoll(2) extension over poll(2).
> > >>
> > >> Signal mask specification in linux requires two parameters:
> > >> "const sigset_t *sigmask" and "size_t sigsetsize".
> > >> Creating pwait6(2) as an extension of wait4(2) with two arguments
> > >> is straightforward.
> > >> Creating pwaitid(2) as an extension of waitid(2) that already has 5
> > >> arguments would require an indirection similar to pselect6(2).
> > >
> > > Getting back to this point: you could also do the same thing with
> > > the CLONE_FD approach from Josh Triplett[1] or Casey Dahlin's
> > > older waitfd() syscall, correct?
> >
> > A descriptor-based solution would not be useful to glibc because
> > applications assume that glibc does not (persistently) open any file
> > descriptors behind t heir back.

*My* long-term goal is to expose all new process-related functionality
as operations on file descriptors. I really don't want to further
complicate the wait*(2) series of functions.

Whether the file descriptor is opened "persistently" or not is an
implementation detail. A multi-threaded program can observe the file
descriptor being open regardless. The right approach here is to
abandon this strange requirement that glibc not use file descriptors
for its own purposes. File descriptors are just kernel resource
handles, and it's not reasonable for applications to expect that the
libraries they use do not manage resources for their own purposes.
This self-imposed never-open-file-descriptors behavior on glibc's part
has created API design problems in the past (e.g., with the randomness
functions) and should be abandoned.

Re: extending wait4(2) or waitid(2) linux syscall

[Florian Weimer]

* Arnd Bergmann:

> On Mon, Nov 26, 2018 at 4:18 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Arnd Bergmann:
>>
>> > On Thu, Nov 15, 2018 at 7:30 AM Dmitry V. Levin <ldv@altlinux.org> wrote:
>> >> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
>> >> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
>> >> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
>> >>
>> >> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
>> >> with a different signal mask, this cannot be achieved without
>> >> an extended version of syscall, similar to pselect6(2) extension
>> >> over select(2) and ppoll(2) extension over poll(2).
>> >>
>> >> Signal mask specification in linux requires two parameters:
>> >> "const sigset_t *sigmask" and "size_t sigsetsize".
>> >> Creating pwait6(2) as an extension of wait4(2) with two arguments
>> >> is straightforward.
>> >> Creating pwaitid(2) as an extension of waitid(2) that already has 5
>> >> arguments would require an indirection similar to pselect6(2).
>> >
>> > Getting back to this point: you could also do the same thing with
>> > the CLONE_FD approach from Josh Triplett[1] or Casey Dahlin's
>> > older waitfd() syscall, correct?
>>
>> A descriptor-based solution would not be useful to glibc because
>> applications assume that glibc does not (persistently) open any file
>> descriptors behind t heir back.
>
> Right, makes sense. What about a temporary file descriptor as discussed
> in the recent procfd() mail thread then? Would that work?
>
> /* for illustration, needs error handling and more features */
> int pwait(pid_t id, siginfo_t *infop)
> {
>       char waitfd_file[MAX_PROCFD_LEN];
>       struct pollfd pfd[1] = { {.events = POLLIN }};
>
>       snprintf(waitfd_file, MAX_PROCFD_LEN, "/proc/%d/wait", pid);
>       pfd.fd = open(waitfd_file,  O_RDONLY);
>       ppoll(&pfd, 1, NULL, sigmask);
>       read(fd, infop, sizeof(*infop));
>       close(fd);
>
>      return 0;
> }

Together with an officiall supported way that allows us that the process
denoted by the PID is still the same that it was, it could work, I
think.

It would also nice to have the ability to launch processes without
making them visible to wait, and trigger SIGCHLD signals, but noticing
process exit seems like a tricky matter under these circumstances.

Thanks,
Florian

Re: extending wait4(2) or waitid(2) linux syscall

[Christian Brauner]

On November 28, 2018 10:31:23 PM GMT+13:00, Florian Weimer <fweimer@redhat.com> wrote:
>* Arnd Bergmann:
>
>> On Mon, Nov 26, 2018 at 4:18 PM Florian Weimer <fweimer@redhat.com>
>wrote:
>>>
>>> * Arnd Bergmann:
>>>
>>> > On Thu, Nov 15, 2018 at 7:30 AM Dmitry V. Levin <ldv@altlinux.org>
>wrote:
>>> >> On Thu, Nov 15, 2018 at 06:39:03AM -0800, Arnd Bergmann wrote:
>>> >> > On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin wrote:
>>> >> > > On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD
>wrote:
>>> >>
>>> >> 1. strace needs a race-free invocation of wait4(2) or waitid(2)
>>> >> with a different signal mask, this cannot be achieved without
>>> >> an extended version of syscall, similar to pselect6(2) extension
>>> >> over select(2) and ppoll(2) extension over poll(2).
>>> >>
>>> >> Signal mask specification in linux requires two parameters:
>>> >> "const sigset_t *sigmask" and "size_t sigsetsize".
>>> >> Creating pwait6(2) as an extension of wait4(2) with two arguments
>>> >> is straightforward.
>>> >> Creating pwaitid(2) as an extension of waitid(2) that already has
>5
>>> >> arguments would require an indirection similar to pselect6(2).
>>> >
>>> > Getting back to this point: you could also do the same thing with
>>> > the CLONE_FD approach from Josh Triplett[1] or Casey Dahlin's
>>> > older waitfd() syscall, correct?
>>>
>>> A descriptor-based solution would not be useful to glibc because
>>> applications assume that glibc does not (persistently) open any file
>>> descriptors behind t heir back.
>>
>> Right, makes sense. What about a temporary file descriptor as
>discussed
>> in the recent procfd() mail thread then? Would that work?

The intention has always been to start a
file descriptor process API off of that.
If we land my procfd_signal() patchset we are in good shape for procfd_wait(), imho.

>>
>> /* for illustration, needs error handling and more features */
>> int pwait(pid_t id, siginfo_t *infop)
>> {
>>       char waitfd_file[MAX_PROCFD_LEN];
>>       struct pollfd pfd[1] = { {.events = POLLIN }};
>>
>>       snprintf(waitfd_file, MAX_PROCFD_LEN, "/proc/%d/wait", pid);
>>       pfd.fd = open(waitfd_file,  O_RDONLY);
>>       ppoll(&pfd, 1, NULL, sigmask);
>>       read(fd, infop, sizeof(*infop));
>>       close(fd);
>>
>>      return 0;
>> }
>
>Together with an officiall supported way that allows us that the
>process
>denoted by the PID is still the same that it was, it could work, I
>think.
>
>It would also nice to have the ability to launch processes without
>making them visible to wait, and trigger SIGCHLD signals, but noticing
>process exit seems like a tricky matter under these circumstances.
>
>Thanks,
>Florian

Re: extending wait4(2) or waitid(2) linux syscall

[Florian Weimer]

* Christian Brauner:

> The intention has always been to start a
> file descriptor process API off of that.
> If we land my procfd_signal() patchset we are in good shape for
> procfd_wait(), imho.

How does this interact with SIGCHLD and the wait system call (or any
wait function without an explicitly specified PID)?

I understand that I have somewhat conflicting requirements, but in terms
of relative priorities, launching a process without spurious signals and
wait notifications would probably offer the larger benefit.

Thanks,
Florian

Re: extending wait4(2) or waitid(2) linux syscall

[Daniel Colascione]

On Wed, Nov 28, 2018 at 1:41 AM, Florian Weimer <fweimer@redhat.com> wrote:
> * Christian Brauner:
>
>> The intention has always been to start a
>> file descriptor process API off of that.
>> If we land my procfd_signal() patchset we are in good shape for
>> procfd_wait(), imho.
>
> How does this interact with SIGCHLD and the wait system call (or any
> wait function without an explicitly specified PID)?

It doesn't, but let's take one step at a time. procfd_signal() is a
good first step. Once procfd_signal() and procfd_wait() exist, and
managing processes with FDs in general no longer seems odd, we can add
a clone() option that 1) avoid wiring a new subprocess up to the
legacy PID-based process-management API, and 2) returns one of these
fancy new FDs that works with procfd_signal and procfd_wait. (How we
do that without /proc mounted is an open question, but solvable in a
few options.)

> I understand that I have somewhat conflicting requirements, but in terms
> of relative priorities, launching a process without spurious signals and
> wait notifications would probably offer the larger benefit.

I also want a non-process-wide subprocess API. A clean FD-based API is
how you get it--- it's not an either-or situation. Considering that we
want to use FDs for general-purpose process management in the future,
it'd be not only a waste of time, but actually counterproductive, to
design a non-FD-based API for this non-process-wide sub-process use
case.

Re: Sixth draft of the Y2038 design document

[hpa]

On November 15, 2018 6:39:03 AM PST, Arnd Bergmann <arnd@arndb.de> wrote:
>On Thu, Nov 15, 2018 at 6:05 AM Dmitry V. Levin <ldv@altlinux.org>
>wrote:
>>
>> Hi,
>>
>> On Thu, Apr 20, 2017 at 03:20:51PM +0200, Albert ARIBAUD wrote:
>> > Hi all,
>> >
>> > I have produced a sixth draft of what will eventually become the
>Y2038
>> > design document:
>> >
>> > https://sourceware.org/glibc/wiki/Y2038ProofnessDesign?rev=146
>> >
>> > Relative to the previous draft:
>> >
>> >  * Precisions re padding in struct timespec was added.
>> >
>> >  * Better separation of APIs and implementations; notably,
>developed
>> >    the distinction between API types and implementation types.
>> >
>> >  * Cleaned up API tables (e.g., removed argument names and left
>types
>> >    only).
>> >
>> >  * Also developed on implementation vs kernel types (e.g., struct
>> >    timespec conversion between GLIB padded versions and kernel non-
>> >    padded versions.
>> >
>> > As always, comments welcome.
>>
>> Is there any rationale for marking wait4 as an obsolete API?
>
>In the *kernel* syscall API, wait4(2) is obsoleted by waitid(2), which
>is
>a strict superset of its functionality.
>
>In the libc API, this is different, as wait4() does not have a
>replacement
>that is exposed to user space directly. I expect glibc to implement
>wait4() on top of the kernel's waitid().
>
>There has not been a final decision on which variant of waitid() that
>would
>be. The easiest option would be to not change it at all: new
>architectures
>(rv32, csky, nanomips/p32, ...) would keep exposing the traditional
>waitid() in Linux, with its 32-bit time_t based rusage structure, but
>drop the
>wait4(). glibc then has to convert between the kernel's rusage and the
>user space rusage indefinitely.
>
>Alternatively, we can create a new version like waitid2() that uses
>64-bit time_t in some form, either the exact same rusage that we
>use on 64-bit architectures and x32, or using a new set of arguments
>to include further improvements.
>
>        Arnd

I vote for waitid64().
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.