mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Daniel Phillips <phillips@arcor.de>
To: Pavel Machek <pavel@ucw.cz>,
	"Richard B. Johnson" <root@chaos.analogic.com>
Cc: "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: Thu, 4 Jul 2002 01:46:57 +0200	[thread overview]
Message-ID: <E17PtqU-0000RJ-00@starship> (raw)
In-Reply-To: <20020703034809.GI474@elf.ucw.cz>

On Wednesday 03 July 2002 05:48, Pavel Machek wrote:
> Hi!
> 
> Okay. So we want modules and want them unload. And we want it bugfree.
> 
> So... then its okay if module unload is *slow*, right?
> 
> I believe you can just freeze_processes(), unload module [now its
> safe, you *know* noone is using that module, because all processes are
> in your refrigerator], thaw_processes().
> 
> That's going to take *lot* of time, but should be very simple and very
> effective.

Hi Pavel,

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.  For smp, an ipi would pick up the current process on each cpu.

At this point the use count must be zero and the module deregistered, so all 
we're interested in is that every process that dec'ed the module's use count 
has succeeded in executing its way out of the module.  If not, we try again 
later, or if we're impatient, also bump any processes still inside the module 
to the front of the run queue.

I'm sure I must have missed something.

-- 
Daniel

  parent reply	other threads:[~2002-07-03 23:55 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-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 [this message]
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
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=E17PtqU-0000RJ-00@starship \
    --to=phillips@arcor.de \
    --cc=davidsen@tmr.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --cc=root@chaos.analogic.com \
    --cc=sct@redhat.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®