Ian Kent <raven@xxxxxxxxxx> writes: > AFAICS kernel/kmod.c used to use create_singlethread_workqueue() and > queue_work() to perform umh calls, now it uses only queue_work() and > the system_unbound_wq workqueue. > > Looking at the workqueue sub system there doesn't appear to be a way to > create a workqueue with a thread runner thread, created within the > process context at the time of workqueue creation, that then waits to > run work. So there's no way to create a workqueue to run umh calls > within a specific process context, such as that of a container, by using > the workqueue subsystem as it is now. > > The problem being that the process context of the caller requesting umh > isn't necessarily (and shouldn't be used because it could allow the > caller to hijack the environment) the process context that needs to be > used for the request. > > It looks like the reply to this thread from Oleg that demonstrates using > child_reaper for the run context could be used though. Capturing the > struct pid of child_reaper and then using that to locate the appropriate > task context later (if it still exists) at request time could be used. > > That doesn't take care of working out when this should be captured or > where to put it so it can be obtained at request time (which seems > difficult in itself). It would be really really nice if the user namespace could be used for the where do we look at case. As every other namespace already has a pointer to the user namespace, and fundamentally the user namespace is the permission boundary (from a namespace perspective). So for the equivalent of kthreadd in a user namespace we need a thread that has a full set of namespaces owned by the user namespaces. On one side this is very easy to obtain if we look at the process that sets core_pattern or mounts one of the nfs filesystems (such as the filesystem that when mounted starts nfsd), and just fork a kernel thread from it. On another side perhaps what we want is a syscall call it start_umhd that says repurpose the caller of this thread to handle future user mode helper calls. That we could tie to a user namespace quite easily. This definitely does not play particularly nice with queue work and friends, but that is just infrastructure and we can update user mode helper to use something else reasonable as long as we have a solid design. Perhaps there is a combination of the two ideas that could work. Instead of a syscall use the invocation of a service that needs a user mode helper as a trigger to create such a launcher thread. Eric -- 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
