Linux-man Archive on
 help / color / Atom feed
From: "Michael Kerrisk (man-pages)" <>
To: Christian Brauner <>
Subject: Re: [PATCH] clone.2: add CLONE_PIDFD entry
Date: Wed, 18 Sep 2019 08:49:59 +0200
Message-ID: <> (raw)
In-Reply-To: <20190916074012.dpsfqfwcxh2pyyt7@wittgenstein>

Hello Christian,

On 9/16/19 9:40 AM, Christian Brauner wrote:
> On Wed, Sep 11, 2019 at 10:58:57AM +0200, Michael Kerrisk (man-pages) wrote:
>> Hello Christian,
>> On 5/11/19 8:49 AM, Christian Brauner wrote:
>>> From: Christian Brauner <>
>>> Add an entry for CLONE_PIDFD. This flag is available starting with
>>> kernel 5.2. If specified, a process file descriptor ("pidfd") referring
>>> to the child process will be returned in the ptid argument.
>> I've applied this patch in a local branch, and made some minor edits
> Thank you! :)
>> and added a piece. And I have some questions. See below.
>>> Signed-off-by: Christian Brauner <>
>>> ---


>>> Note, that the kernel verifies that the value for
>>> +.I ptid
>>> +is zero. If it is not an error will be returned. This ensures that
>>> +.I ptid
>>> +can potentially be used to specify additional options for
>>> +in the future.
>> This piece is no longer true, right? At least I can't see such 
> Correct.

Thanks. Page amended.

>> a check in the kernel code, and my testing doesn't yield an error
>> when ptid != 0 before the call.(No need to send me a patch; if I'm
>> correct just let me know and I'll edit out this piece.)
>>> +.IP
>>> +Since the
>>> +.I ptid
>>> +argument is used to return the pidfd,
>>> +cannot be used with
>>> +.IP
>>> +It is currently not possible to use this flag together with
>>> +This means that the process identified by the pidfd will always be a
>>> +thread-group leader.
>>> +.IP
>>> +For a while there was a
>>> +flag. This flag is usually ignored when passed along with other flags.
>>> +However, when passed alongside
>>> +an error will be returned. This ensures that this flag can be reused
>>> +for further pidfd features in the future.
>>> +.TP
>>>  .BR CLONE_PTRACE " (since Linux 2.2)"
>>>  If
>>> @@ -1122,6 +1158,21 @@ For example, on aarch64,
>>>  .I child_stack
>>>  must be a multiple of 16.
>>>  .TP
>>> +.B EINVAL
>>> +was specified together with
>>> +.TP
>>> +.B EINVAL
>>> +was specified together with
>>> +.TP
>>> +.B EINVAL
>>> +was specified together with
>>> +.TP
>>>  .B ENOMEM
>>>  Cannot allocate sufficient memory to allocate a task structure for the
>>>  child, or to copy those parts of the caller's context that need to be
>> One other piece seems to be missing: the returned file descriptor can
>> be fed to poll()/select()/epoll and the FD will test as readable when
>> the child terminates. Right? Did that functionality also land in
>> kernel 5.2? And did it get implemented as a separate commit, or did
>> the behavior just fall naturally out of the implementation of pidfd's?
>> Let me know the details, and I will craft a patch.
> It landed in 5.3. The relevant commit is:
> and belongs to the following merge:

Thanks for that info. One other questions springs to mind.
I haven't looked at the source or tried testing this,
but can anything actually be read() from a PIDFD? Presumably,
it might be useful to have data generated on the FD, since
different values could (ultimately) be used to distinguish
between terminate/stopp/continue transitions.

>> Also, as far as I can see (from testing) the FD only gives pollable
>> events on process termination, not on other process transitions such
>> as stop and continue. Right? (Are there any plans to implement such
> Correct.
>> functionality for stop/contine transitions?
> Yes, at some point we will likely want this.
>> By the way, when do you expect the pidfd-wait functionality to land 
>> in the kernel?
> I've sent a PR for 5.4:
> which contains the P_PIDFD extension to waitid().

Thanks for that pointer. I see that the code is
now merged.

> Thanks for the work, Michael!

You're welcome!



Michael Kerrisk
Linux man-pages maintainer;
Linux/UNIX System Programming Training:

  reply index

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <>
2019-09-11  8:58 ` Michael Kerrisk (man-pages)
2019-09-16  7:40   ` Christian Brauner
2019-09-18  6:49     ` Michael Kerrisk (man-pages) [this message]
2019-09-18  7:14       ` Christian Brauner
2019-09-19  4:04         ` Michael Kerrisk (man-pages)
2019-09-19  4:43           ` Michael Kerrisk (man-pages)
2019-09-19  6:47           ` Christian Brauner
2019-09-23  8:11             ` Michael Kerrisk (man-pages)
2019-09-23 14:13               ` Christian Brauner

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-man Archive on

Archives are clonable:
	git clone --mirror linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ \
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone