Hello Christian,

> We originally blocked this because it is not as easy as simply allowing
> pidfds to be created for non-thread-group leaders.
> For a start, pidfd_poll() currently doens't work if pidfd_task() isn't a
> thread-group leader

I did notice the hang there, that's why my patch changes pidfd_poll to return
error on tasks which are not thread-group leaders. IIRC, waiting on specific
threads is not supported by Linux at all, so I don't see a problem with not
supporting it here either.

> and you'll just hang for CLONE_PIDFD | CLONE_THREAD.

No, CLONE_PIDFD | CLONE_THREAD behavior is unchanged, it will still fail with
EINVAL. I actually confirmed this by double-checking right now.

> So at least that needs to be adapated as well and there's likely a bunch
> of other corner-cases I'm forgetting about.

I'd be happy to hear about other corner-cases so I can fix them.

> Do you have a concrete use-case you want this for?

My use-case is basically making pidfd_getfd actually useful for its intended
purpose: there is a seccomp_unotify-based supervisor that wants to obtain a
file descriptor from its guest. This currently does not work if the action to
be forwarded to the supervisor is performed in a secondary thread, since there
is no way to obtain the required pidfd.

> Christian

Alois