Re: + daemonize-detach-from-current-namespace.patch added to -mmtree

[Eric W. Biederman]

Arjan van de Ven <arjan@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/