mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Keith Owens <kaos@ocs.com.au>
To: linux-kernel@vger.kernel.org
Subject: Re: [OKS] Module removal
Date: Tue, 09 Jul 2002 10:27:46 +1000	[thread overview]
Message-ID: <22226.1026174466@ocs3.intra.ocs.com.au> (raw)
In-Reply-To: Your message of "Mon, 08 Jul 2002 21:07:13 -0300." <20020708210713.R2295@almesberger.net>

On Mon, 8 Jul 2002 21:07:13 -0300, 
Werner Almesberger <wa@almesberger.net> wrote:
>What troubles me most in this discussion is that nobody seems to
>think of how these issues affect non-modules.
>
>Entry-after-removal is an anomaly in the subsystem making that call.
>Fixing it for modules is fine as long as only modules will ever
>un-register, but what do you do if non-module code ever wants to
>un-register too ? (E.g. think hot-plugging or software devices.)

The only difference between module and non-module is whether the code
and data areas are freed or left in the kernel for the next user.  All
other processing should be the same for hotplug.  This is why
CONFIG_HOTPLUG retains the __exit code in the kernel instead of
discarding it at link time.

>Besides, a common pattern for those "hold this down, kick that, then
>slowly count to ten, and now it's safe to release" solutions seems
>to be that it takes roughly ten times as long to find the race
>condition buried deep within them, than it took for the respective
>predecessor.

I don't like 'wait for n seconds then release' methods, as you say they
just hide the problem.  Neither Rusty nor I are suggesting that
approach.  Rusty's idea is

  Check use count.
  Unregister.
  Ensure that all code that had a reference to the module has either
  dropped that reference or bumped the use count.
  Check use count again, it may have been bumped above.
  If use count is still 0, there are no stale references left.  It is
  now safe to unload, call the module unallocate routine then free its
  area.
  If use count != 0, either schedule for removal when the count goes to
  0 or reregister.  I prefer reregister, Rusty prefers delayed removal.

Ensuring that all code has either dropped stale references or bumped
the use count means that all processes that were not sleeping when
rmmod was started must proceed to a sync point.  It is (and always has
been) illegal to sleep while using module code/data (note: using, not
referencing).


  reply	other threads:[~2002-07-09  0:25 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
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 [this message]
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=22226.1026174466@ocs3.intra.ocs.com.au \
    --to=kaos@ocs.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /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®