On Mon, 18 Nov 2013 19:02:59 +0100 Oleg Nesterov <oleg@xxxxxxxxxx> wrote: > On 11/18, Oleg Nesterov wrote: > > > > On 11/15, Eric W. Biederman wrote: > > > > > > I don't understand that one. Having a preforked thread with the proper > > > environment that can act like kthreadd in terms of spawning user mode > > > helpers works and is simple. > > > > Can't we ask ->child_reaper to create the non-daemonized kernel thread > > with the "right" ->nsproxy, ->fs, etc? > > > > IOW. Please the the "patch" below. It is obviously incomplete and wrong, > > and it can be more clear/clean. And probably we need another API. Just > > to explain what I mean. > > Or, perhaps UMH_IN_MY_NS should only work if ->child_reaper explicitly > does, say, prctl(PR_SPAWN_UMH_IN_NS_HELPER) which forks the non-daemonized > kernel kthread_worker thread, I dunno. > > Oleg. > Neat idea. So is it always the case that tasks in a container have the same namespace settings and capabilities as the child_reaper? We'll still have the basic problem for nfsd that we'll need to keep track of what the child_reaper is when nfsd is started, but I think that's not too hard to solve. -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
