linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/4] net, pidfs: enable handing out pidfds for reaped sk->sk_peer_pid
@ 2025-04-25  8:11 Christian Brauner
  2025-04-25  8:11 ` [PATCH v2 1/4] pidfs: register pid in pidfs Christian Brauner
                   ` (5 more replies)
  0 siblings, 6 replies; 9+ messages in thread
From: Christian Brauner @ 2025-04-25  8:11 UTC (permalink / raw)
  To: Oleg Nesterov, Kuniyuki Iwashima, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Simon Horman
  Cc: linux-kernel, linux-fsdevel, netdev, David Rheinsberg, Jan Kara,
	Alexander Mikhalitsyn, Luca Boccassi, Lennart Poettering,
	Daan De Meyer, Mike Yuan, Christian Brauner

SO_PEERPIDFD currently doesn't support handing out pidfds if the
sk->sk_peer_pid thread-group leader has already been reaped. In this
case it currently returns EINVAL. Userspace still wants to get a pidfd
for a reaped process to have a stable handle it can pass on.
This is especially useful now that it is possible to retrieve exit
information through a pidfd via the PIDFD_GET_INFO ioctl()'s
PIDFD_INFO_EXIT flag.

Another summary has been provided by David in [1]:

> A pidfd can outlive the task it refers to, and thus user-space must
> already be prepared that the task underlying a pidfd is gone at the time
> they get their hands on the pidfd. For instance, resolving the pidfd to
> a PID via the fdinfo must be prepared to read `-1`.
>
> Despite user-space knowing that a pidfd might be stale, several kernel
> APIs currently add another layer that checks for this. In particular,
> SO_PEERPIDFD returns `EINVAL` if the peer-task was already reaped,
> but returns a stale pidfd if the task is reaped immediately after the
> respective alive-check.
>
> This has the unfortunate effect that user-space now has two ways to
> check for the exact same scenario: A syscall might return
> EINVAL/ESRCH/... *or* the pidfd might be stale, even though there is no
> particular reason to distinguish both cases. This also propagates
> through user-space APIs, which pass on pidfds. They must be prepared to
> pass on `-1` *or* the pidfd, because there is no guaranteed way to get a
> stale pidfd from the kernel.
> Userspace must already deal with a pidfd referring to a reaped task as
> the task may exit and get reaped at any time will there are still many
> pidfds referring to it.

In order to allow handing out reaped pidfd SO_PEERPIDFD needs to ensure
that PIDFD_INFO_EXIT information is available whenever a pidfd for a
reaped task is created by PIDFD_INFO_EXIT. The uapi promises that reaped
pidfds are only handed out if it is guaranteed that the caller sees the
exit information:

TEST_F(pidfd_info, success_reaped)
{
        struct pidfd_info info = {
                .mask = PIDFD_INFO_CGROUPID | PIDFD_INFO_EXIT,
        };

        /*
         * Process has already been reaped and PIDFD_INFO_EXIT been set.
         * Verify that we can retrieve the exit status of the process.
         */
        ASSERT_EQ(ioctl(self->child_pidfd4, PIDFD_GET_INFO, &info), 0);
        ASSERT_FALSE(!!(info.mask & PIDFD_INFO_CREDS));
        ASSERT_TRUE(!!(info.mask & PIDFD_INFO_EXIT));
        ASSERT_TRUE(WIFEXITED(info.exit_code));
        ASSERT_EQ(WEXITSTATUS(info.exit_code), 0);
}

To hand out pidfds for reaped processes we thus allocate a pidfs entry
for the relevant sk->sk_peer_pid at the time the sk->sk_peer_pid is
stashed and drop it when the socket is destroyed. This guarantees that
exit information will always be recorded for the sk->sk_peer_pid task
and we can hand out pidfds for reaped processes.

Note, I'm marking this as RFC mostly because I'm open to other
approaches to solving the pidfs registration. The functionality in
general we should really provide either way.

Link: https://lore.kernel.org/lkml/20230807085203.819772-1-david@readahead.eu [1]
Signed-off-by: Christian Brauner <brauner@kernel.org>
---
Changes in v2:
- Fix typo in pidfs_register_pid() kernel documentation.
- Remove SOCK_RCU_FREE check as it's already and better covered by might_sleep().
- Add comment to pidfd_prepare() about PIDFD_STALE only being valid if
  the caller knows PIDFD_INFO_EXIT information is guaranteed to be
  available.
- Fix naming of variables and adhere to net declaration ordering.
- Link to v1: https://lore.kernel.org/20250424-work-pidfs-net-v1-0-0dc97227d854@kernel.org

---
Christian Brauner (4):
      pidfs: register pid in pidfs
      net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid
      pidfs: get rid of __pidfd_prepare()
      net, pidfs: enable handing out pidfds for reaped sk->sk_peer_pid

 fs/pidfs.c                 | 80 ++++++++++++++++++++++++++++++++++++++-----
 include/linux/pid.h        |  2 +-
 include/linux/pidfs.h      |  3 ++
 include/uapi/linux/pidfd.h |  2 +-
 kernel/fork.c              | 83 ++++++++++++++++----------------------------
 net/core/sock.c            | 14 +++-----
 net/unix/af_unix.c         | 85 ++++++++++++++++++++++++++++++++++++++++------
 7 files changed, 183 insertions(+), 86 deletions(-)
---
base-commit: b590c928cca7bdc7fd580d52e42bfdc3ac5eeacb
change-id: 20250423-work-pidfs-net-bc0181263d38


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2025-04-26  6:29 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-04-25  8:11 [PATCH v2 0/4] net, pidfs: enable handing out pidfds for reaped sk->sk_peer_pid Christian Brauner
2025-04-25  8:11 ` [PATCH v2 1/4] pidfs: register pid in pidfs Christian Brauner
2025-04-25  8:11 ` [PATCH v2 2/4] net, pidfs: prepare for handing out pidfds for reaped sk->sk_peer_pid Christian Brauner
2025-04-25 20:46   ` Kuniyuki Iwashima
2025-04-25  8:11 ` [PATCH v2 3/4] pidfs: get rid of __pidfd_prepare() Christian Brauner
2025-04-25  8:11 ` [PATCH v2 4/4] net, pidfs: enable handing out pidfds for reaped sk->sk_peer_pid Christian Brauner
2025-04-25 20:47   ` Kuniyuki Iwashima
2025-04-25  8:38 ` [PATCH v2 0/4] " David Rheinsberg
2025-04-26  6:28 ` Christian Brauner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).