On April 18, 2019 4:10:20 PM GMT+02:00, Oleg Nesterov <oleg@xxxxxxxxxx> wrote: >On 04/18, Christian Brauner wrote: >> >> On Thu, Apr 18, 2019 at 03:12:07PM +0200, Oleg Nesterov wrote: >> > Should we allow CLONE_THREAD | CLONE_PIDFD ? >> >> I think so, yes. I have thought about this. > >OK, I won't insist. But let me explain why did I ask. > >> Yes, due to CLONE_FILES | >> CLONE_VM you'd necessarily hand the pidfd to the child but threads >are >> no security boundary in the first place. > >No, no, I am not not worried about security. CLONE_PARENT | CLONE_PIDFD >looks more problematic to me, but I see nothing dangerous >security-wise.. > >I agree that CLONE_THREAD | CLONE_PIDFD may be usefule, but I am not >sure >we should allow this from the very begining, until we have a "real" >use-case. > >IIUC, we are going to make it pollable soon. OK, but >proc_tgid_base_poll() >(which should be turned into pidfd_poll) simply can't work if >pid_task() is >not a group leader. poll(pidfd) will hang forever if pidfd was created >by >CLONE_THREAD | CLONE_PIDFD. > >Sure, we can (should?) improve pidfd_poll() but this will need more >nasty >changes in the core kernel code. Do we really need/want this? Right now >it >is not clear to me. Instead, we can simply disallow >CLONE_THREAD|CLONE_PIDFD >until we decide that yes, we want to poll sub-threads. If you think that makes the polling work simpler for Joel then for sure. And yes, I have argued for "disable until someone needs it" often before so I can't really argue the other way around here. :) I'll send an updated version soon. Christian > >But again, I am fine with CLONE_THREAD | CLONE_PIDFD. > >Oleg.
