Messages in this thread | | | From | Alois Wohlschlager <> | Subject | Re: [PATCH] pid: Allow creation of pidfds to threads | Date | Fri, 01 Apr 2022 11:00:27 +0200 |
| |
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 [unhandled content-type:application/pgp-signature] | |