"Serge E. Hallyn" <[email protected]> writes:
> Quoting Rusty Russell ([email protected]):
>> On Thu, 2006-06-15 at 22:04 -0500, Serge E. Hallyn wrote:
>> > Quoting Rusty Russell ([email protected]):
>> > > Seems like change for change's sake, to me, *and* it added more code
>> > > than it removed.
>> >
>> > So if kernel_thread is really going to be removed, how else should this
>> > be done? Just clone?
>>
>> Sorry, is kernel_thread going to be removed, or just not exported to
>> modules? What's kthread going to use?
>>
>> Confused,
>> Rusty.
>
> Hah.
>
> Yes, I see. I misread. So I should be focusing on modules :)
>
> Really, all *I* care about is cases where the resulting pid is cached
> as a pointer to the thread, which it wasn't here anyway.
There is one other piece we care about as well.
We don't want to capture user space context like a non-default fs namespace
in a kernel thread as well. Since the kthread api calls kernel_thread
from keventd non of the threads that it spawns can capture any user
space context, by accident. There was a very nasty bug a while ago
when the fs namespace was captured by a kernel thread and then it was
impossible to unmount your filesystem because no one had access to
that filesystem mount tree.
In this instance the kstopmachine is stared using the kthread api so
it is safe, and then forking children is safe as well.
Once everything that we can convert to the kthread api is converted we
need to audit all of the remaining kernel_thread instances to ensure
they don't capture user space context.
The basic rule is that is only safe to use kernel_thread directly if
it is coming from another kernel thread.
So while the conversion was overkill in this context and we certainly
want to concentrate on modules, where it is much less likely to be
correct. We want to convert as many instances as we can away from
the raw kernel_thread api.
All that is ultimately going away is the export of kernel_thread to
modules, because there are so very few instances when using
kernel_thread directly can be justified.
Eric
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
