LWN: Comments on "A new filesystem for pidfds"

A new filesystem for pidfds

NYKevin — Tue, 19 Mar 2024 07:04:32 +0000

> It's also a problem that only the parent can do the wait. You can't pass ownership of the subprocess to another process this way.

Technically, you can sorta kinda hand the ownership to another process by passing PR_SET_CHILD_SUBREAPER to prctl(2), but there are so many caveats with this method that it's not even funny:

* The destination process must be an ancestor of you.
* You have to orphan the child process, which means you have to do a double-fork.
* It is a global (process-wide) flag on the destination process, which makes it assume ownership of all orphaned processes under it, not just your particular process. If the destination does not periodically call wait, it will leak zombies until it dies.
* It is really meant to be used by things like systemd. If you are not implementing something that resembles systemd, there are probably other pitfalls I'm unaware of.

In short: This may be reasonable if you are trying to make an entirely self-contained self-managing all-singing all-dancing daemon that does all of its own bookkeeping, sessions, etc., but in practice you're probably better off configuring systemd to do those things for you instead, unless you're one of those sysvinit-or-death people.

A new filesystem for pidfds

bluca — Thu, 14 Mar 2024 09:52:39 +0000

That only helps if it's the parent process that needs to reliably identify another process. That is not the case, and hasn't been for years.

A new filesystem for pidfds

roc — Thu, 14 Mar 2024 08:14:12 +0000

It's extra-annoying because waitpid() only has a limited set of options for what you can wait for. You can't choose an arbitrary set of processes to wait on.

It's also a problem that only the parent can do the wait. You can't pass ownership of the subprocess to another process this way.

A new filesystem for pidfds

ibukanov — Thu, 14 Mar 2024 04:29:17 +0000

A pid can only be recycled after the parent process called waitpid or related methods. Thus in a properly written application there should be no race when using the pid.

However that does complicate the code especially when one writes a library that wants to start external process as arranging for waitpid call becomes problematic.

A new filesystem for pidfds

pcmoore — Thu, 14 Mar 2024 02:44:05 +0000

It's frustrating that all of these decisions around LSM hooks and the SELinux implementation were done without CC'ing the LSM or SELinux mailing lists. We need to improve collaboration across Linux kernel subsystems, and adding the appropriate CCs to a discussion - even part way through the discussion - should be standard practice.

A new filesystem for pidfds

magfr — Thu, 14 Mar 2024 01:46:03 +0000

But why is that a hindrance for clone to return an fd in procfd? Sure, there might not be any link to it left under /proc but that is no problem, is it?

A new filesystem for pidfds

am — Thu, 14 Mar 2024 00:21:26 +0000

systemd-pidpidfdfsfdd.service - a clever solution to a difficult problem that you never realized you've always had!

A new filesystem for pidfds

fraetor — Wed, 13 Mar 2024 22:49:18 +0000

IIRC the main difference is that you can only get the pidfd from /proc after the process has been created. This leaves (at least a little) time for the desired process to exit and the pid to recycled for another process.

This race condition is one of the main things pidfds exist to fix, so it's better to get the fd immediately at process creation.

A new filesystem for pidfds

NYKevin — Wed, 13 Mar 2024 21:46:48 +0000

According to pidfd_open(2), opening /proc/pid *does* give you a pidfd, but it has a few minor restrictions compared to a properly-obtained pidfd (from pidfd_open(2) or clone(2)). I am uncertain of the reason for those restrictions, but it does look like there was a conscious decision to create two different kinds of pidfd. Maybe someone who actually knows what they're talking about can shed further light on this issue.

A new filesystem for pidfds

ianmcc — Wed, 13 Mar 2024 18:05:14 +0000

Why wasn't /proc/pid reused for this? If there was a way to access /proc without it being mounted, then that would seem to solve some other problems.

A new filesystem for pidfds

mattdm — Wed, 13 Mar 2024 17:37:21 +0000

Agreed -- thanks, LWN!

A new filesystem for pidfds

bluca — Wed, 13 Mar 2024 13:20:22 +0000

And already queued for 6.10, a new way to get a reference to the new filesystem: a pidfdfsfd. Which then unlocks the possibility of querying which process holds such a ref, by getting a pidpidfdfsfd. Which then brings us...

A new filesystem for pidfds

jkingweb — Wed, 13 Mar 2024 12:20:04 +0000

What a journey. That was a fun read.