Messages in this thread | | | Subject | Re: + daemonize-detach-from-current-namespace.patch added to -mm tree | From | (Eric W. Biederman) | Date | Mon, 20 Feb 2006 02:04:27 -0700 |
| |
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/
| |