From: ebiederm@xmission.com (Eric W. Biederman)
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Paul Mackerras <paulus@samba.org>,
lkml - Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] kthread: convert stop_machine into a kthread
Date: Sun, 18 Jun 2006 06:12:15 -0600 [thread overview]
Message-ID: <m1wtbek6hs.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20060616125403.GA16194@sergelap.austin.ibm.com> (Serge E. Hallyn's message of "Fri, 16 Jun 2006 07:54:03 -0500")
"Serge E. Hallyn" <serue@us.ibm.com> writes:
> Quoting Rusty Russell (rusty@rustcorp.com.au):
>> On Thu, 2006-06-15 at 22:04 -0500, Serge E. Hallyn wrote:
>> > Quoting Rusty Russell (rusty@rustcorp.com.au):
>> > > 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
next prev parent reply other threads:[~2006-06-18 12:13 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <17553.56625.612931.136018@cargo.ozlabs.ibm.com>
2006-06-16 1:04 ` [PATCH] kthread: convert stop_machine into a kthread Rusty Russell
2006-06-16 3:04 ` Serge E. Hallyn
2006-06-16 3:54 ` Paul Mackerras
2006-06-16 4:00 ` Rusty Russell
2006-06-16 12:54 ` Serge E. Hallyn
2006-06-18 12:12 ` Eric W. Biederman [this message]
2006-06-15 14:43 Serge E. Hallyn
2006-06-20 3:14 ` Andrew Morton
2006-06-20 3:20 ` Erik Ohrnberger
2006-06-20 8:27 ` Serge E. Hallyn
2006-06-20 8:40 ` Andrew Morton
2006-06-20 16:27 ` Serge E. Hallyn
2006-06-20 22:42 ` Andrew Morton
2006-06-21 0:52 ` Serge E. Hallyn
2006-06-21 1:18 ` Andrew Morton
2006-06-21 1:44 ` Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1wtbek6hs.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulus@samba.org \
--cc=rusty@rustcorp.com.au \
--cc=serue@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox