public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Alexander Viro <viro@math.psu.edu>
Cc: Roman Zippel <zippel@linux-m68k.org>
Cc: Daniel Phillips <phillips@arcor.de>,
	"David S. Miller" <davem@redhat.com>,
	adam@yggdrasil.com, R.E.Wolff@bitwizard.nl,
	linux-kernel@vger.kernel.org
Subject: Re: Rusty's module talk at the Kernel Summit
Date: Fri, 12 Jul 2002 13:53:27 +1000	[thread overview]
Message-ID: <20020712035658.83B41412D@lists.samba.org> (raw)
In-Reply-To: Your message of "Thu, 11 Jul 2002 19:37:17 -0400." <Pine.GSO.4.21.0207111928390.9488-100000@weyl.math.psu.edu>

In message <Pine.GSO.4.21.0207111928390.9488-100000@weyl.math.psu.edu> you writ
e:
> For filesystems the only currently existing race is in the case when
> init_module() registers one, then decides to bail out and unregisters it.
> If somebody finds the thing between register/unregister the current code
> is screwed.  And no, "don't block in between" is not viable - typically
> the reason of failure is failing allocation and/or timeouts on some sort
> of probing.

Yes.  Of course, drivers tend to be more lax about registering things
*then* setting up the internal stage than filesystems, so they have a
race even without failure (this is, of course, entirely soluble one
driver at a time).

> As for determining the loading/normal/unloading - we _already_ have that
> state, no need to introduce new fields.  How do you think try_inc_mod_count()
> manages to work?  Exactly - there's a field of struct module that contains
> a bunch of flags.  And no, Daniel's ramblings (from what I've seen quoted)
> are pure BS - there's no need to mess with "oh, but I refuse to be
> unregistered"; proper refcounting is easy for normal cases.

try_inc_mod_count() is a hack.  I'm not allergic to hacks: from a
purist POV, any module solution short of "anything can be a module" is
a hack, but you should realize its weaknesses.

As implemented, it results in spurious failure.  Failing to do
something because the module was being removed at the time, and
falling back to module load fails because the old module hasn't
released some resource yet.

> It's not needed.  I don't see where this ret-rmmod crap is coming from -
> module uses some interface and decisions about holding it pinned belong
> to that interface.  Plain, simple and works for all normal drivers.

Sure, but you must define what interfaces modules are allowed to use,
Al.  And any module using an interface not on those lists can't be
unloaded.

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

  parent reply	other threads:[~2002-07-12  3:53 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-04 17:24 Rusty's module talk at the Kernel Summit Adam J. Richter
2002-07-11  2:48 ` Rusty Russell
2002-07-11  2:45   ` David S. Miller
2002-07-11  3:30     ` Alexander Viro
2002-07-11  5:13       ` Rusty Russell
2002-07-11  6:37         ` Alexander Viro
2002-07-11  7:14           ` Rusty Russell
2002-07-11 10:54             ` Daniel Phillips
2002-07-11 17:37               ` Roman Zippel
2002-07-11 18:01                 ` Thunder from the hill
2002-07-11 18:50                   ` Daniel Phillips
2002-07-17 18:16                   ` bill davidsen
2002-07-17 19:35                     ` Thunder from the hill
2002-07-11 18:28                 ` Daniel Phillips
2002-07-11 19:48                   ` Roman Zippel
2002-07-11 20:29                     ` Daniel Phillips
2002-07-11 23:37                     ` Alexander Viro
2002-07-12  1:54                       ` Daniel Phillips
2002-07-12  3:53                       ` Rusty Russell [this message]
2002-07-12  6:49                         ` Kai Henningsen
2002-07-12 11:30                       ` Roman Zippel
2002-07-12  0:00               ` Rusty Russell
2002-07-12  6:57                 ` Kai Henningsen
2002-07-19  0:19           ` Richard Gooch
2002-07-22 16:29             ` Alexander Viro
2002-07-23  4:37               ` Richard Gooch
2002-07-11  4:02     ` Cort Dougan
2002-07-11  4:19       ` Arnaldo Carvalho de Melo
2002-07-11  4:46       ` Cort Dougan
2002-07-11  2:55   ` Arnaldo Carvalho de Melo
2002-07-11  3:01     ` Arnaldo Carvalho de Melo
2002-07-11  5:16     ` Rusty Russell
  -- strict thread matches above, loose matches on Subject: below --
2002-07-11  5:44 Adam J. Richter
2002-07-11  5:07 Adam J. Richter
2002-07-03 15:53 Adam J. Richter
2002-07-03 17:07 ` Hugh Dickins
2002-07-03 18:46   ` Oliver Neukum
2002-07-03 23:25     ` Keith Owens
2002-07-03 23:09 ` Keith Owens
2002-07-03  7:31 Adam J. Richter
2002-07-03  8:54 ` Rogier Wolff
2002-07-03 12:27 ` Keith Owens
2002-07-03 14:10   ` Keith Owens
2002-07-01 17:20 Adam J. Richter
2002-07-01 16:12 Adam J. Richter
2002-07-01 17:02 ` jlnance
2002-07-03  5:01 ` Keith Owens
2002-07-01  8:45 Keith Owens

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=20020712035658.83B41412D@lists.samba.org \
    --to=rusty@rustcorp.com.au \
    --cc=viro@math.psu.edu \
    --cc=zippel@linux-m68k.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