From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-3.9 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 253901F461 for ; Tue, 23 Jul 2019 08:12:34 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=toOy S35DcKWz4D1seQmBqt/hxRN5VkNX7AFXEvm1llt1rIgVY9YlEj5S4BYjV9GEOBXS uohgp+pItOYuZTiRxIfyQYI962rgz8uM08eMHRAyjwUuGiZWD4grHYvOa3CDSW9x GpEFn1FwIZjbYvrZxoC2GFH86kegugjfel9KhTI= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=CtbPR80xnQ bs+jCkGRi+WwoAylY=; b=x3QizfeehW0tqtvuOH2rOshg97aA59x8Bkprh0lRfG /XuF8NJmqbuHAy9qDVEUO5Sm8yUQxxLbKKQxq33YdK2b7ipg3P0r43ErWgtyzjYg Dvn9MoRHrlhORPZJHYTjsfXQs40mVFsSsuLn0m0sj020fvOjkTvC/qzLIC3xB1Gp Y= Received: (qmail 112262 invoked by alias); 23 Jul 2019 08:12:29 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 112248 invoked by uid 89); 23 Jul 2019 08:12:28 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-qt1-f195.google.com MIME-Version: 1.0 References: <2d3359a195633b85e01f83bf536330d72f7bc8aa.1563321715.git.alistair.francis@wdc.com> <20190721040310.GA3283@brightrain.aerifal.cx> <87o91nbn37.fsf@xmission.com> <87muh79yt2.fsf@xmission.com> <87blxn83sk.fsf@xmission.com> <20190721232336.GA30851@brightrain.aerifal.cx> <87k1c962ml.fsf@xmission.com> In-Reply-To: <87k1c962ml.fsf@xmission.com> From: Arnd Bergmann Date: Tue, 23 Jul 2019 10:12:07 +0200 Message-ID: Subject: Re: [RFC v3 03/23] sysdeps/wait: Use waitid if avaliable To: "Eric W. Biederman" Cc: Rich Felker , Linus Torvalds , Alistair Francis , GNU C Library , Adhemerval Zanella , Florian Weimer , Palmer Dabbelt , macro@wdc.com, Zong Li , Alistair Francis , Andrew Morton , Al Viro , Christian Brauner , "H. Peter Anvin" Content-Type: text/plain; charset="UTF-8" On Tue, Jul 23, 2019 at 2:01 AM Eric W. Biederman wrote: > Rich Felker writes: > > On Sun, Jul 21, 2019 at 04:40:27PM -0500, Eric W. Biederman wrote: > >> Linus Torvalds writes: > > I'm in agreement that if an extension to the waitid syscall is added, > > it should be P_PROCESS_PGID, not defining some special case for > > pid==0. It's not entirely clear but arguable that the standard > > requires EINVAL for P_PGID + pid==0, and plausible that there are > > applications that depend on this. We could emulate the EINVAL case in > > userspace, but assigning weird semantics to special cases is just a > > mess of potential future headaches when it would be trivial to do it > > right. And doing it right would also make programming userspace side > > easier. > > Since this is a POSIX interface and shared between many unices I took > at look at a couple to see what they have done. If possible it is > important to be able to write programs that work the same across > different unices. > > The BSDs implemented wait6 as their common wait that does everything > system call. It's large contribution is that wait6 will give both > the rusage of the child that exited and it's children separately. Ah right, that was one more thing I forgot on my earlier list. If we end up creating a new wait4()/waitid() replacement to replace the timeval with __kernel_timespec, we may want that to return a wrusage instead of rusage. Same for Christian's proposed pidfd_wait(). > So my recommendation now is to avoid gratuitous incompatibilities. > > 1) For extending waitid. Let's use P_PGID and and id of 0 to represent > the callers process group. That is compatible with the BSDs, and > portable programs should not have any problem with it. > > I want to stay away from the BSD extention of P_PID with an id of 0 > meaning wait for the calling process's process group. I see where > it comes from but that is confusing. > > 2) It appears the popular definition of current process group is the > current process group at the time of the system call. Currently that > is Linux, FreeBSD, Illumos, and XNU. So short of a real program that > cares, let's adopt that definition in linux. Along with patches I > will see about getting the linux manpage updated to clarify that > point. That all sounds reasonable to me, thanks for researching the other implementations! Arnd