All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Christian Brauner <brauner@kernel.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
	Tycho Andersen <tycho@tycho.pizza>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/1] pidfd: implement PIDFD_THREAD flag for pidfd_open()
Date: Wed, 31 Jan 2024 17:10:53 +0100	[thread overview]
Message-ID: <20240131161053.GC2609@redhat.com> (raw)
In-Reply-To: <20240131-engel-entern-9b5c96659948@brauner>

On 01/31, Christian Brauner wrote:
>
> On Wed, Jan 31, 2024 at 03:12:04PM +0100, Oleg Nesterov wrote:
> >
> > After this patch we can easily add another feature, pidfd_poll()
> > can add, say, POLLHUP to poll_flags if the pid is "dead".
> >
> > So the user can do
> >
> > 	poll(pidfd, { .revents = POLLHUP });
> >
> > and it will block until release_task() is called and this pid is
> > no longer in use (pid_task() == NULL).
> >
> > Do you think this can be useful?
>
> Yeah, I think this is something that people would find useful. IIUC, it
> would essentially allow them to do things like wait until a task has
> been waited upon

Exactly.

OK. I'll try to make the (hopefully simple) patch on top of this one
on Friday, if Tycho agrees with V3. Will be busy tomorrow.

> * systemd completely relying on pidfds to manage services to guard
>   against any pid races.
> * Extended dbus to allow authentication via pidfds.
> * Extended policy kit to enable secure authentication of processes via pidfds.
> * Language support for pidfds: Go, Rust etc.
> * An endless number of tools that added support for them.
> * glibc support for pidfd apis.
>
> There's a bunch more. That literally obliterated whole bug classes.

Thanks for this info!

Not that I ever thouhgt that pidfd is "useless", not at all, but as I said
(and as a Perl progammer ;) I simply do not know what people actually do with
pidfds ;)

Oleg.


      reply	other threads:[~2024-01-31 16:12 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-31 13:25 [PATCH v3 0/1] pidfd: implement PIDFD_THREAD flag for pidfd_open() Oleg Nesterov
2024-01-31 13:26 ` [PATCH v3 1/1] " Oleg Nesterov
2024-01-31 14:12   ` Christian Brauner
2024-01-31 14:19     ` Oleg Nesterov
2024-01-31 17:23   ` Tycho Andersen
2024-01-31 18:01     ` Oleg Nesterov
2024-01-31 18:15       ` Christian Brauner
2024-02-01  7:23   ` kernel test robot
2024-02-01  8:47     ` Oleg Nesterov
2024-02-01 17:25   ` Christian Brauner
2024-02-01 18:10     ` Oleg Nesterov
2024-02-02 12:50   ` Christian Brauner
2024-02-05 15:22     ` Oleg Nesterov
2024-02-06 13:38       ` Christian Brauner
2024-02-08  7:54   ` kernel test robot
2024-02-08  8:58     ` Christian Brauner
2024-02-08  9:18       ` Oleg Nesterov
2024-01-31 13:58 ` [PATCH v3 0/1] " Christian Brauner
2024-01-31 14:12 ` Oleg Nesterov
2024-01-31 14:39   ` Christian Brauner
2024-01-31 16:10     ` Oleg Nesterov [this message]

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20240131161053.GC2609@redhat.com \
    --to=oleg@redhat.com \
    --cc=brauner@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tycho@tycho.pizza \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.