From: Jamie Lokier <lk@tantalophile.demon.co.uk>
To: Werner Almesberger <wa@almesberger.net>
Cc: Bill Davidsen <davidsen@tmr.com>, Keith Owens <kaos@ocs.com.au>,
linux-kernel@vger.kernel.org
Subject: Re: [OKS] Module removal
Date: Sun, 7 Jul 2002 22:09:34 +0100 [thread overview]
Message-ID: <20020707220933.B11999@kushida.apsleyroad.org> (raw)
In-Reply-To: <20020704035012.O2295@almesberger.net>; from wa@almesberger.net on Thu, Jul 04, 2002 at 03:50:12AM -0300
Werner Almesberger wrote:
> Okay, here's an almost correct example (except for the usual
> return-after-removal, plus an unlikely data race described
> below). foo_1 runs first:
This can be fixed if we assume a way to ask "is any CPU still executing
module code?".
To do this, have the `free_module' function use `smp_call_function' to
ask every CPU "are you executing code for module XXX?". The question is
answered by a routine which walks the stack, checking the instruction
pointer at each place on the stack to see whether it's inside the module
of interest.
Yes this is complex, but it's not that complex -- provided you can rely
on stack walking to find the module. (It wouldn't work if x86 used
-fomit-frame-pointer, for example).
So module removal works like this:
int free_module(...)
{
/* ...stuff... */
if (module->uc.usecount != 0)
return -EAGAIN;
if (smp_call_function (check_if_in_module, module, 1, 1))
return -EGAIN;
/* remove module. */
}
Admittedly, this _only_ deals with this particular class of race
conditions.
Another possibility would be the RCU thing: execute the module's exit
function, but keep the module's memory allocated until some safe
scheduling point later, when you are sure that no CPU can possibly be
running the module.
These don't help at all with races against parallel opens -- food for
thought, though.
-- Jamie
next prev parent reply other threads:[~2002-07-07 21:08 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-01 20:21 RE2: " Michael Nguyen
2002-07-02 1:40 ` Werner Almesberger
2002-07-02 2:25 ` Keith Owens
2002-07-02 3:11 ` Werner Almesberger
2002-07-02 3:42 ` Keith Owens
2002-07-02 4:11 ` Werner Almesberger
2002-07-02 22:23 ` Alexander Viro
2002-07-09 19:23 ` Russ Lewis
2002-07-02 4:08 ` Brian Gerst
2002-07-02 4:53 ` Keith Owens
2002-07-02 5:43 ` Werner Almesberger
2002-07-02 16:36 ` Werner Almesberger
2002-07-02 16:50 ` Benjamin Herrenschmidt
2002-07-02 18:05 ` Werner Almesberger
2002-07-03 3:50 ` Pavel Machek
2002-07-04 4:11 ` Bill Davidsen
2002-07-04 6:29 ` Werner Almesberger
2002-07-04 6:50 ` Werner Almesberger
2002-07-07 21:09 ` Jamie Lokier [this message]
2002-07-07 21:41 ` Oliver Neukum
2002-07-08 0:31 ` Jamie Lokier
2002-07-08 6:42 ` Oliver Neukum
2002-07-08 0:18 ` Bill Davidsen
2002-07-08 0:46 ` Jamie Lokier
2002-07-08 6:22 ` Daniel Phillips
2002-07-08 10:16 ` Bill Davidsen
2002-07-09 0:07 ` Werner Almesberger
2002-07-09 0:27 ` Keith Owens
2002-07-09 3:09 ` Werner Almesberger
2002-07-09 6:25 ` Roman Zippel
2002-07-09 8:59 ` Kai Germaschewski
2002-07-09 11:06 ` Roman Zippel
2002-07-04 12:29 ` Bill Davidsen
2002-07-09 1:50 ` Kevin O'Connor
2002-07-09 2:37 ` Werner Almesberger
2002-07-02 23:35 ` Alexander Viro
2002-07-02 22:41 ` RE2: " Alexander Viro
2002-07-02 8:52 ` Helge Hafting
2002-07-02 16:22 ` Werner Almesberger
-- strict thread matches above, loose matches on Subject: below --
2002-07-02 12:20 Ariel Garcia
2002-07-01 17:48 Bill Davidsen
2002-07-01 18:35 ` Richard B. Johnson
2002-07-01 18:42 ` Jose Luis Domingo Lopez
2002-07-01 18:45 ` Shawn
2002-07-01 19:57 ` Diego Calleja
2002-07-01 20:03 ` Diego Calleja
2002-07-01 22:20 ` Jose Luis Domingo Lopez
2002-07-01 22:56 ` Ryan Anderson
2002-07-02 11:37 ` Stephen C. Tweedie
2002-07-02 12:04 ` Richard B. Johnson
2002-07-02 13:13 ` jlnance
2002-07-02 15:20 ` Bill Davidsen
2002-07-02 15:53 ` Jonathan Corbet
2002-07-02 16:07 ` Oliver Neukum
2002-07-02 17:48 ` Tom Rini
2002-07-02 18:10 ` Oliver Neukum
2002-07-02 21:50 ` Ryan Anderson
2002-07-03 22:26 ` Diego Calleja
2002-07-04 0:00 ` Keith Owens
2002-07-04 8:04 ` Helge Hafting
2002-07-02 16:08 ` Werner Almesberger
[not found] ` <Pine.LNX.3.95.1020702075957.24872A-100000@chaos.analogic.c om>
2002-07-04 8:36 ` Mike Galbraith
2002-07-03 0:09 ` Vojtech Pavlik
2002-07-12 21:51 ` David Lang
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=20020707220933.B11999@kushida.apsleyroad.org \
--to=lk@tantalophile.demon.co.uk \
--cc=davidsen@tmr.com \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=wa@almesberger.net \
/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®