On 04/06, Eric W. Biederman wrote: > > Oleg Nesterov <[EMAIL PROTECTED]> writes: > > >> At first glance your patch looks reasonable. > >> > >> Unfortunately it only applies to the rare thread that calls daemonize, > >> and not also to kernel/kthread/kthread() which means it will miss many of > >> our current kernel threads. > > > > Note that a thread created by kthread_create() has ->parent == "[kthread]", > > not /sbin/init (unless it was created before core_initcall). So I don't > > really > > understand how stop_machine() creates the threads parented to init. > > Duh. I was looking for that detail but the code was sufficiently > abstracted that I missed it skimming through. Now I see it thanks. > That at least explains how a handful of threads created with > kthread_create have init as their parent.
Oops. I misread stop_machine(), it does kernel_thread(), not kthread_create(). So "stopmachine" threads are all re-parented to init when the caller exits. I think it makes sense to set ->exit_state = -1 in stopmachine(), regadless of any other changes. > My gut feel says it makes sense to change reparent_to_init to > reparent_to_kthread. Which will get the all of the kernel daemons > under a single parent. Further I think it makes sense to see if > we can start kthread earlier. Having kthread have pid == 2 would be > nice. That way we can kill the conditional that is only used during > early initialization (make the code simpler and more predictable). Yes. But we can't create helper_wq ([kthread]) before init_workqueues(). We can call helper_init() from init_workqueues() before creating "events" though. Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
