lkml.org 
[lkml]   [2022]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] pid: Allow creation of pidfds to threads
Date
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]
\
 
 \ /
  Last update: 2022-04-01 11:02    [W:0.083 / U:0.008 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site