From patchwork Wed Aug 14 20:50:41 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christian Brauner X-Patchwork-Id: 34108 Received: (qmail 29038 invoked by alias); 14 Aug 2019 20:50:48 -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 Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 28582 invoked by uid 89); 14 Aug 2019 20:50:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-16.9 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=pub X-HELO: youngberry.canonical.com Date: Wed, 14 Aug 2019 22:50:41 +0200 From: Christian Brauner To: Oleg Nesterov Cc: linux-kernel@vger.kernel.org, libc-alpha@sourceware.org, alistair23@gmail.com, ebiederm@xmission.com, arnd@arndb.de, dalias@libc.org, torvalds@linux-foundation.org, adhemerval.zanella@linaro.org, fweimer@redhat.com, palmer@sifive.com, macro@wdc.com, zongbox@gmail.com, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, hpa@zytor.com Subject: Re: [PATCH v3 1/1] waitid: Add support for waiting for the current process group Message-ID: <20190814205040.d7shwe6u3jz6qmcc@wittgenstein> References: <20190814154400.6371-1-christian.brauner@ubuntu.com> <20190814154400.6371-2-christian.brauner@ubuntu.com> <20190814160917.GG11595@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20190814160917.GG11595@redhat.com> User-Agent: NeoMutt/20180716 On Wed, Aug 14, 2019 at 06:09:17PM +0200, Oleg Nesterov wrote: > On 08/14, Christian Brauner wrote: > > > > and a signal could come in between the system call that > > retrieved the process gorup and the call to waitid that changes the > ^^^^^ > > current process group. > > I noticed this typo only because I spent 2 minutes or more trying to > understand this sentence ;) But yes, a signal handler or another thread > can change pgrp in between. > > Reviewed-by: Oleg Nesterov Applied-to: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=pidfd on top of P_PIDFD changes (cf. [1]) with merge conflict resolved (cf. [2]). (All changes on top of v5.3-rc1.) Merged-into: https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=for-next and should show up in linux-next tomorrow. Thanks! Christian /* References */ [1]: https://lore.kernel.org/r/20190727222229.6516-2-christian@brauner.io [2]: patch after resolved merge-conflict: kernel/exit.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/exit.c b/kernel/exit.c index 64bb6893a37d..d2d74a7b81d1 100644 --- a/kernel/exit.c +++ b/kernel/exit.c @@ -1596,10 +1596,13 @@ static long kernel_waitid(int which, pid_t upid, struct waitid_info *infop, break; case P_PGID: type = PIDTYPE_PGID; - if (upid <= 0) + if (upid < 0) return -EINVAL; - pid = find_get_pid(upid); + if (upid) + pid = find_get_pid(upid); + else + pid = get_task_pid(current, PIDTYPE_PGID); break; case P_PIDFD: type = PIDTYPE_PID;