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

[Paolo Abeni]

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@xxxxxxxxxx>
> Signed-off-by: Andrew Halaney <andrew@xxxxxxxxxxxx>
>
> ---
> 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@xxxxxxxxxxxx
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