Re: [PATCH v4 00/10] net: support thread-specific pidfds for send and connect

On 10/5/26 17:09, Andrew Halaney wrote:

SO_PASSPIDFD/SCM_PIDFD and SO_PEERPIDFD allow to retrieve a pidfd for
the thread-group leader. The coredump server using the coredump socket
cannot get a handle on the task that took the signal and is writing the
coredump easily. Workloads interested in per-thread authentification
have similar problems.

Add SO_PASSPIDFD_THREAD/SCM_PIDFD_THREAD and SO_PEERPIDFD_THREAD. We
record the sending and the connecting thread in addition to the
thread-group leader.

SO_PASSPIDFD_THREAD functions like SO_PASSPIDFD but instead of an
SCM_PIDFD message for the thread-group leader, SCM_PIDFD_THREAD sends a
pidfd for the specific thread. SO_PASSPIDFD / SO_PASSPIDFD_THREAD are
independent, allowing callers to get both styles of pidfd back in their
cmsg.

SO_PEERPIDFD_THREAD allows to retrieve a pidfd for the specific thread
that called connect(), listen(), or socketpair().

pidfs_coredump() now also stamps the dumping thread's struct pid so a
pidfd for that thread reports the coredump like the pidfd of the
thread-group leader does.

Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
Signed-off-by: Andrew Halaney <redacted>

---
Changes in v4:
- Moved get_pid() out of scm_set_cred() into scm_send() (Kuniyuki)
- Dropped unnecessary helps (Kuniyuki)
- Rebased on v7.3-r6
- Collected Kuniyuki's RB tags
- Link to v3: https://lore.kernel.org/r/20260928-work-unix-passpidfd-v3-0-532018a91b21@amutable.com (local)

Out of sheer ignorance, I don't see the shared, stable tree where we
can pull from, can you please point that out?

I think that this late in the cycle, the series could go via Christian's
tree only and we could get it back after the merge window. WDYT?

Thanks,

Paolo