![]() | |||||||||||||
Messages in this thread |
Arjan van de Ven <arjan@infradead.org> writes: >> diff -puN kernel/exit.c~daemonize-detach-from-current-namespace kernel/exit.c >> --- devel/kernel/exit.c~daemonize-detach-from-current-namespace 2006-02-19 > 20:36:58.000000000 -0800 >> +++ devel-akpm/kernel/exit.c 2006-02-19 20:36:58.000000000 -0800 >> @@ -360,6 +360,9 @@ void daemonize(const char *name, ...) >> fs = init_task.fs; >> current->fs = fs; >> atomic_inc(&fs->count); >> + exit_namespace(current); >> + current->namespace = init_task.namespace; >> + get_namespace(current->namespace); >> exit_files(current); > > not that it'll matter much here, but this is normally the wrong order of > refcounting ;) First take the count, then start using it ;) Well what would need in a general case situation here would be task_lock, for the two tasks. Having that as long as all of the operations happened under the lock it wouldn't matter. In this case the init_task is known not to change, and no one else should be messing with current. I am beginning to suspect that we will want to fix kernel_thread so it creates copies of the init_task rather than copies of whatever random user space process we happen to be a member of at the time. With an enhanced kernel_thread this problem could more easily avoided, as we add additional namespaces to the kernel. The problem with a kernel thread running in a private namespace like this is that you can't kill the kernel thread and when it is the last user of a private namespace. So you can never free up your mounts etc. As for this patch in particular matching the style that is already there for a bug fix seems to make a lot of sense :) Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2006-02-20 10:08 [from the cache] ©2003-2008 | |||||||||||||