This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC v3 03/23] sysdeps/wait: Use waitid if avaliable


On Sun, Jul 21, 2019 at 5:45 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> > On Sun, Jul 21, 2019 at 2:15 PM Eric W. Biederman <ebiederm@xmission.com> wrote:
> >> Arnd Bergmann <arnd@arndb.de> writes:
> >> > On Sun, Jul 21, 2019 at 6:03 AM Rich Felker <dalias@libc.org> wrote:
> >> >> On Tue, Jul 16, 2019 at 05:08:48PM -0700, Alistair Francis wrote:
> > - The race that Rich pointed out
> > - The lack of pidfd support
> > - The usage of a 32-bit timeval structure that is incompatible with
> >   the libc definition on rv32 and other 32-bit architectures with
> >   a y2038-safe libc (there is no y2038 overflow in rusage itself, but
> >   it requires an ugly wrapper to convert the structure)
> > - The lack of nanosecond resolution in rusage that someone asked for
> > - When we last talked about it, there was some debate over replacing
> >   siginfo_t with a different structure.
> >
> > We don't have to address each one of those in a single new syscall
> > (or even at all), but addressing them one at a time would risk adding
> > even more system calls to do essentially just one thing that already
> > has at least five versions at the libc level (wait, waitpid, wait3, wait4
> > and waitid).
>
> For the particular issue of 32bit riscv needing a working wait4 I see
> one of two possibilities.
>
> We either add P_PROCESS_PGID to the kernel's waitid or we add wait4.
>
> I am leaning towards P_PROCESS_PGID as this is the tiny little bit
> needed to make the kernel's waitid the one call that combines them all,
> that it already tries to be.  Plus P_PROCESS_PGID or the equivalent in
> the kernel internal version is needed if we choose to have wait4 handle
> the process group id changing while wait4 is running.

Yes, that sounds good to me, both as a short-term and as a long-term
solution for the race, on all architectures. It would help if we could
have some extra review on the wait4() and waitpid() implementation
around waitid(). I first implemented this in my prototype for a y2038-safe
musl port, and Alistair write a corresponding version for glibc.

I did make sure that it passes LTP (and that found a number of bugs
in my first attempt), but it would still be good to know that the P_PGID
issue is the only problem in the underlying system call, aside from
any remaining bugs in the wrapper implementation.

        Arnd


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]