From: Stephen Tweedie <sct@redhat.com>
To: Daniel Phillips <phillips@arcor.de>
Cc: Pavel Machek <pavel@ucw.cz>,
"Richard B. Johnson" <root@chaos.analogic.com>,
"Stephen C. Tweedie" <sct@redhat.com>,
Bill Davidsen <davidsen@tmr.com>,
Linux-Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: simple handling of module removals Re: [OKS] Module removal
Date: Fri, 5 Jul 2002 10:40:49 +0100 [thread overview]
Message-ID: <20020705104049.H27198@redhat.com> (raw)
In-Reply-To: <20020703234750Z16173-11563+874@humbolt.nl.linux.org>; from phillips@arcor.de on Thu, Jul 04, 2002 at 01:48:59AM +0200
Hi,
On Thu, Jul 04, 2002 at 01:48:59AM +0200, Daniel Phillips
<phillips@arcor.de> wrote:
> Is it just the mod_dec_use_count; return/unload race we're worried about?
> I'm not clear on why this is hard. I'd think it would be sufficient just to
> walk all runnable processes to ensure none has an execution address inside the
> module.
That fails if:
the module function has called somewhere else in the kernel (and
with -fomit-frame-pointer, you can't reliably walk back up the stack
to find out if there is a stack frame higher up the stack which is in
the module);
the module has taken an interrupt into an unrelated driver;
we have computed a call into the module but haven't actually executed
the call yet;
etc.
> For smp, an ipi would pick up the current process on each cpu.
Without freezing the other CPUs, that still leaves the race wide open.
--Stephen
next prev parent reply other threads:[~2002-07-05 10:38 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-01 17:48 [OKS] Module removal 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-03 3:48 ` simple handling of module removals " Pavel Machek
2002-07-03 17:25 ` Richard B. Johnson
2002-07-03 23:46 ` Daniel Phillips
2002-07-08 12:21 ` Richard B. Johnson
2002-07-08 12:41 ` Thunder from the hill
2002-07-08 12:57 ` Richard B. Johnson
2002-07-08 13:58 ` Thunder from the hill
2002-07-08 15:48 ` Daniel Gryniewicz
2002-07-08 17:23 ` Thunder from the hill
2002-07-08 13:06 ` Keith Owens
2002-07-08 13:15 ` Keith Owens
2002-07-03 23:48 ` Daniel Phillips
2002-07-05 9:40 ` Stephen Tweedie [this message]
2002-07-06 19:40 ` Daniel Phillips
2002-07-06 19:47 ` Pavel Machek
2002-07-04 1:18 ` Keith Owens
2002-07-04 1:53 ` Andrew Morton
2002-07-04 4:00 ` Keith Owens
2002-07-04 2:25 ` Brian Gerst
2002-07-04 3:54 ` David Gibson
2002-07-04 4:08 ` Keith Owens
2002-07-04 15:02 ` Brian Gerst
2002-07-04 19:18 ` Werner Almesberger
2002-07-05 13:48 ` Pavel Machek
2002-07-07 14:56 ` Keith Owens
2002-07-07 22:36 ` Roman Zippel
2002-07-08 1:09 ` Daniel Mose
2002-07-09 17:07 ` Daniel Mose
2002-07-08 18:13 ` Pavel Machek
2002-07-08 22:43 ` Keith Owens
2002-07-09 14:00 ` Pavel Machek
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
[not found] <0C01A29FBAE24448A792F5C68F5EA47D2B0A8A@nasdaq.ms.ensim.com>
2002-07-04 0:29 ` simple handling of module removals " pmenage
2002-07-04 0:59 ` Daniel Phillips
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=20020705104049.H27198@redhat.com \
--to=sct@redhat.com \
--cc=davidsen@tmr.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=phillips@arcor.de \
--cc=root@chaos.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.