Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp13812668pxu; Mon, 4 Jan 2021 05:18:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJx3i+SlFTQTTkx13hnJeGwEJzZQSml16tIXiqMq0QtrRrgoqfWzM3CgygD9iYK68jxKkH7H X-Received: by 2002:a17:906:7784:: with SMTP id s4mr66945657ejm.93.1609766314209; Mon, 04 Jan 2021 05:18:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609766314; cv=none; d=google.com; s=arc-20160816; b=XrSdU8rKHbWJPParsCiqL2CuO+2VZcS4Www9vHIX0RndsZABoAQa7CUN7jFDUus7JX qvF0exuTIdtCyZIyDZregT8/quKCMtpeCB5uPGPCEHhL9H6O5FznusMZYTz0/0rORxYI QU9txoXPDLlpYbkq/yBk8eu1mtW9+ABVdI2PnuLBz0HYMoqTa4JERFQu3f+Me1Vsr49S 9w3Goc0n+RG/AIJXwwnoj4ZGDP4nw2gEWrVW8PdOhLm+CDBlO+EejJqLYwFDx+4BL90Z pIOB32aHw1hKz3g8C9WHY5f7HWe2ZmF1u1CCPY04MLxHoP3IPMXcn2ROs8B8f3v8dmJE 35gg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Wf+e4ngvRVXk1Pt3ALYXbvvwG1Ha6GClSS3XM2+BuOU=; b=H/24rDM5Dv4Ag2H3P2jRUw8n/i6K0vVuiMQJyl4IzjDnYmXvG/j7uc71obonnyavU2 3QZ30tyOxUQo/S8SLUf1h81DtsizW32cALpY11S9kCrJcj7tXEEmOLQ64Em9SOKyl4wN iPB/U87qTk389sDiqb3MpAwyalEGSjcOw/T0pqGg2Lx588lhEmIbfMX2n7W1XNimxOiM j1ISI4onuyO+Wdz+4Yl6zjokS7HjKv/nb+iCuJBhr8v0JP5PmQNrQxyY2zeuWAIodI+7 qEhxRQYofbkKzWM3W3peP2VWmSyDnhDyIL8c5ApvNr1XWIUgfC7CwRT1NHoMH2jE3Anp haAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=fxFW8mC7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h6si24400790edf.132.2021.01.04.05.18.10; Mon, 04 Jan 2021 05:18:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=fxFW8mC7; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726616AbhADNQz (ORCPT + 99 others); Mon, 4 Jan 2021 08:16:55 -0500 Received: from mail.kernel.org ([198.145.29.99]:35034 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726300AbhADNQz (ORCPT ); Mon, 4 Jan 2021 08:16:55 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id D8E0E20658; Mon, 4 Jan 2021 13:16:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1609766174; bh=+tPuG5j1lbs6FQwt3ZCQ8PZl6s+WdQjF21F2p2Ifv7I=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=fxFW8mC7n8zzbi7gMK0pqlXc/O1w0meucg02Eok9J0TRygyfhUZV7luAGQZlkDpnN 58uqoW4IvEI9eWw7vexcl7Nbj10kg0Vuh8+T32mgkjyBi2e+7BrmWHX+9np6tC43Be aV6+igoHT+tvAESmyhbKx7kmkaO0ieXEulL8Ahq4= Date: Mon, 4 Jan 2021 14:17:40 +0100 From: Greg Kroah-Hartman To: Christian Brauner Cc: Wen Yang , Sasha Levin , Xunlei Pang , linux-kernel@vger.kernel.org, Christian Brauner , Linus Torvalds , Jann Horn , Oleg Nesterov , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , Thomas Gleixner , David Howells , "Michael Kerrisk (man-pages)" , Andy Lutomirsky , Andrew Morton , Aleksa Sarai , Al Viro , stable@vger.kernel.org Subject: Re: [PATCH 01/10] clone: add CLONE_PIDFD Message-ID: References: <20201203183204.63759-1-wenyang@linux.alibaba.com> <20201203183204.63759-2-wenyang@linux.alibaba.com> <20210104131342.avhphyfxthtrj6vj@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210104131342.avhphyfxthtrj6vj@wittgenstein> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 04, 2021 at 02:13:42PM +0100, Christian Brauner wrote: > On Mon, Jan 04, 2021 at 02:03:14PM +0100, Greg Kroah-Hartman wrote: > > On Fri, Dec 04, 2020 at 02:31:55AM +0800, Wen Yang wrote: > > > From: Christian Brauner > > > > > > [ Upstream commit b3e5838252665ee4cfa76b82bdf1198dca81e5be ] > > > > > > This patchset makes it possible to retrieve pid file descriptors at > > > process creation time by introducing the new flag CLONE_PIDFD to the > > > clone() system call. Linus originally suggested to implement this as a > > > new flag to clone() instead of making it a separate system call. As > > > spotted by Linus, there is exactly one bit for clone() left. > > > > > > CLONE_PIDFD creates file descriptors based on the anonymous inode > > > implementation in the kernel that will also be used to implement the new > > > mount api. They serve as a simple opaque handle on pids. Logically, > > > this makes it possible to interpret a pidfd differently, narrowing or > > > widening the scope of various operations (e.g. signal sending). Thus, a > > > pidfd cannot just refer to a tgid, but also a tid, or in theory - given > > > appropriate flag arguments in relevant syscalls - a process group or > > > session. A pidfd does not represent a privilege. This does not imply it > > > cannot ever be that way but for now this is not the case. > > > > > > A pidfd comes with additional information in fdinfo if the kernel supports > > > procfs. The fdinfo file contains the pid of the process in the callers > > > pid namespace in the same format as the procfs status file, i.e. "Pid:\t%d". > > > > > > As suggested by Oleg, with CLONE_PIDFD the pidfd is returned in the > > > parent_tidptr argument of clone. This has the advantage that we can > > > give back the associated pid and the pidfd at the same time. > > > > > > To remove worries about missing metadata access this patchset comes with > > > a sample program that illustrates how a combination of CLONE_PIDFD, and > > > pidfd_send_signal() can be used to gain race-free access to process > > > metadata through /proc/. The sample program can easily be > > > translated into a helper that would be suitable for inclusion in libc so > > > that users don't have to worry about writing it themselves. > > > > > > Suggested-by: Linus Torvalds > > > Signed-off-by: Christian Brauner > > > Co-developed-by: Jann Horn > > > Signed-off-by: Jann Horn > > > Reviewed-by: Oleg Nesterov > > > Cc: Arnd Bergmann > > > Cc: "Eric W. Biederman" > > > Cc: Kees Cook > > > Cc: Thomas Gleixner > > > Cc: David Howells > > > Cc: "Michael Kerrisk (man-pages)" > > > Cc: Andy Lutomirsky > > > Cc: Andrew Morton > > > Cc: Aleksa Sarai > > > Cc: Linus Torvalds > > > Cc: Al Viro > > > Cc: # 4.9.x > > > (clone: fix up cherry-pick conflicts for b3e583825266) > > > Signed-off-by: Wen Yang > > > --- > > > include/linux/pid.h | 1 + > > > include/uapi/linux/sched.h | 1 + > > > kernel/fork.c | 119 +++++++++++++++++++++++++++++++++++++++++++-- > > > 3 files changed, 117 insertions(+), 4 deletions(-) > > > > > > diff --git a/include/linux/pid.h b/include/linux/pid.h > > > index 97b745d..7599a78 100644 > > > --- a/include/linux/pid.h > > > +++ b/include/linux/pid.h > > > @@ -73,6 +73,7 @@ struct pid_link > > > struct hlist_node node; > > > struct pid *pid; > > > }; > > > +extern const struct file_operations pidfd_fops; > > > > > > static inline struct pid *get_pid(struct pid *pid) > > > { > > > diff --git a/include/uapi/linux/sched.h b/include/uapi/linux/sched.h > > > index 5f0fe01..ed6e31d 100644 > > > --- a/include/uapi/linux/sched.h > > > +++ b/include/uapi/linux/sched.h > > > @@ -9,6 +9,7 @@ > > > #define CLONE_FS 0x00000200 /* set if fs info shared between processes */ > > > #define CLONE_FILES 0x00000400 /* set if open files shared between processes */ > > > #define CLONE_SIGHAND 0x00000800 /* set if signal handlers and blocked signals shared */ > > > +#define CLONE_PIDFD 0x00001000 /* set if a pidfd should be placed in parent */ > > > #define CLONE_PTRACE 0x00002000 /* set if we want to let tracing continue on the child too */ > > > #define CLONE_VFORK 0x00004000 /* set if the parent wants the child to wake it up on mm_release */ > > > #define CLONE_PARENT 0x00008000 /* set if we want to have the same parent as the cloner */ > > > diff --git a/kernel/fork.c b/kernel/fork.c > > > index b64efec..076297a 100644 > > > --- a/kernel/fork.c > > > +++ b/kernel/fork.c > > > @@ -11,7 +11,22 @@ > > > * management can be a bitch. See 'mm/memory.c': 'copy_page_range()' > > > */ > > > > > > +#include > > > #include > > > +#if 0 > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > +>>>>>>> b3e58382... clone: add CLONE_PIDFD > > > +#endif > > > > That looks odd :( > > > > Can you please refresh this patch series, and make sure it is correct > > and resend it? > > Uhm, this patch series has been merged at least a year ago so this looks > like an accidental send. > This probably isn't meant for upstream but for some alibaba specific > kernel I'd reckon. This was ment for the 4.19.y kernel to solve a problem reported in patch 00/XX of the series. thanks, greg k-h