From: Kyle Moffett <mrmacman_g4@mac.com>
To: Kristis Makris <kristis.makris@asu.edu>
Cc: "linux-os (Dick Johnson)" <linux-os@analogic.com>,
linux-kernel@vger.kernel.org
Subject: Re: [ham] Re: Gracefully killing kswapd, or any kernel thread
Date: Wed, 7 Sep 2005 18:31:42 -0400 [thread overview]
Message-ID: <491A850F-8667-4AF8-AF26-7849C5E6275B@mac.com> (raw)
In-Reply-To: <1126127233.2743.25.camel@syd.mkgnu.net>
On Sep 7, 2005, at 17:07:12, Kristis Makris wrote:
>> To kill a kernel thread, you need to make __it__ call exit(). It
>> must be
>
> There must be another way to do it. Perhaps one could have another
> process effectively issue the contents of do_exit for the kswapd
> task_struct ?
Umm, so then the kernel does what, exactly? You have a process in some
indeterminate state, possibly holding semaphores, definitely pinning
memory/resources/etc, and you just stop it, turn it off, and expect
things to continue working? This is similar in nature to that thread
a while ago about kernel error recovery and killing uninterruptible
user processes. To extend this to kernel threads, unless the kernel
thread has been _specifically_ coded to be interruptible, it isn't, and
furthermore, *can't* be.
>> CODED to do that! You can't do it externally although you can send
>
> I'm clearly asking for the case where the thread wasn't coded to do
> that.
You can't. This is flatly impossible. Go see the thread a while back
about a hot-patch system call for several reasons why that is a bad
idea. In particular, look at the post that discusses phone switches,
the one with the quote "'So why don't you just reboot the affected
switches?' [...] 'That assumes the switches had ever been booted in
the first place'".
>> it a signal, after which it will spin forever....
>
> kflushd and keventd don't seem to spin forever. I still haven't
> determined what makes kswapd spin forever after it receives the
> signal.
Probably a while(1) loop that isn't intended to stop until the machine
physically powers off. If you want to patch one specific kernel thread,
you might be able to do that, but you can't just expect to hot-patch
random parts of the kernel at runtime and have things work.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+
++) E
W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+++) 5
X R?
tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
next prev parent reply other threads:[~2005-09-07 22:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-07 19:41 Kristis Makris
2005-09-07 20:08 ` linux-os (Dick Johnson)
2005-09-07 21:07 ` [ham] " Kristis Makris
2005-09-07 22:31 ` Kyle Moffett [this message]
2005-09-07 22:36 ` linux-os (Dick Johnson)
2005-09-09 18:51 ` Kristis Makris
2005-09-09 19:20 ` linux-os (Dick Johnson)
2005-09-09 22:20 ` Kristis Makris
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=491A850F-8667-4AF8-AF26-7849C5E6275B@mac.com \
--to=mrmacman_g4@mac.com \
--cc=kristis.makris@asu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-os@analogic.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
all inboxes | Powered by JetHome®