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

[Florian Weimer <fweimer@redhat.com>]

* 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