From: Rusty Russell <rusty@rustcorp.com.au>
To: Jamie Lokier <lk@tantalophile.demon.co.uk>
Cc: Daniel Phillips <phillips@arcor.de>,
Oliver Neukum <oliver@neukum.name>,
Roman Zippel <zippel@linux-m68k.org>,
Alexander Viro <viro@math.psu.edu>,
kaos@ocs.com.au, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Raceless module interface
Date: Thu, 12 Sep 2002 13:13:16 +1000 [thread overview]
Message-ID: <20020912031345.760A32C061@lists.samba.org> (raw)
In-Reply-To: Your message of "Thu, 12 Sep 2002 03:09:33 +0100." <20020912030933.A13608@kushida.apsleyroad.org>
In message <20020912030933.A13608@kushida.apsleyroad.org> you write:
> I don't see the point in this at all.
Yes, I'm starting to realize that.
Frankly, I'm sick of pointing out the same problems individually to
every shallow thinker who thinks that "it's easy".
The fundamental problems with modules are as follows:
A) Many places in the kernel do not increment module reference counts
for you, and it is difficult currently write a module which safely
looks after its own reference counts (see
net/ipv4/netfilter/ip_conntrack_core.c's ip_conntrack_cleanup())
B) We do not handle the "half init problem" where a module fails to load, eg.
a = register_xxx();
b = register_yyy();
if (!b) {
unregister_xxx(a);
return -EBARF;
}
Someone can start using "a", and we are in trouble when we remove
the failed module.
Suggested solutions come in several forms, with different mixtures of
the following:
1) Poor man's pageable kernel:
o Every interface in the kernel takes a struct module *, and
looks after the reference counts before and after it jumps in.
o Variants with/without try_inc_mod_count() or
two-stage unload.
o try_inc_mod_count variant solves the half-init problem
2) Modules carry their own overhead:
o Modules can look after their own reference counts.
o "don't sleep until you've grabbed a refcount" & wait
for quiescence.
o Two-stage module delete (stop & destroy).
o More advanced variations allow "restart" of stopped
module if race is lost.
o Still leaves the half-init problem
3) Deprecate module unload:
o Don't unload modules except by kernel hacking config option.
o Unloading in-use modules: "don't do that".
o Still leaves the half-init problem
4) Two-stage module init
o "Reserve" (can fail) and "use" (can't fail).
o Solves ONLY the half-init problem
5) Primordial Soup:
o Module loading/activation and deactivation/destruction occur
in a state similar to the kernel at boot.
o You need to stop all tasks but the loader and some kernel
threads, even if module load sleeps.
o You probably want to defer almost all interrupts, too.
o Or you can make module_init in interrupt context,
which breaks lots of register_xxx interfaces.
(1) PRO: Simple to write modules.
CON: try_inc_mod_count is a source of random subsystem failure.
CON: Everyone pays the inc/dec price even if they're not a module.
CON: Massive infrastructure change
CON: Modules started as a cute hack, are they really worth this cost?
(2) PRO: Non-modules don't pay the overhead for inc/dec.
CON: Harder to write modules than (1).
CON: Gracefully handling the "lost the race between stop and
cleanup" adds complexity
(3) PRO: Infrastructure simple.
PRO: Module implementation simple.
CON: Some broken drivers (eg. 16-bit PCMCIA) require unload to
reset (PCMCIA rewrite and/or suspend hooks can help here).
CON: Judging "unused" from userspace is fun & racy on real systems.
CON: We never remove features from Linux.
(4) PRO: Some drivers register things before setting up their internal
state already (which works fine at boot). This would solve
that, too.
PRO: Can be implemented naively, so if a module doesn't have
two-stage init, we just never free the module memory (still
dangerous since there other resources, but no worse than
before).
CON: Requires more work for module authors in future.
(5) PRO: Infrastructure simple.
PRO: Module implementation simple.
PRO: Would fix drivers which register too early, too.
CON: I'm not smart enough to implement it (esp. before 31 October).
CON: Scheduler magic lots of fun to keep common case efficient.
CON: Deferring interrupts may have interesting side effects.
CON: May not be possible without deadlock?
CON: "stop the world" during module load may piss off some.
Cheers,
Rusty.
--
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
next prev parent reply other threads:[~2002-09-12 3:08 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-04 18:02 Question about pseudo filesystems Jamie Lokier
2002-09-07 12:00 ` Daniel Phillips
2002-09-07 13:36 ` Alexander Viro
2002-09-07 18:27 ` Jamie Lokier
2002-09-07 19:47 ` Alexander Viro
2002-09-08 2:21 ` Jamie Lokier
2002-09-08 2:43 ` Alexander Viro
2002-09-15 1:41 ` Moving a mount point (was Re: Question about pseudo filesystems) Rob Landley
2002-09-08 16:00 ` Question about pseudo filesystems Daniel Phillips
2002-09-09 19:48 ` Jamie Lokier
2002-09-09 20:06 ` Daniel Phillips
2002-09-10 0:44 ` Jamie Lokier
2002-09-10 1:40 ` Daniel Phillips
2002-09-10 1:56 ` Jamie Lokier
2002-09-10 2:53 ` Daniel Phillips
2002-09-10 3:26 ` Jamie Lokier
2002-09-10 3:47 ` Daniel Phillips
2002-09-10 9:15 ` Daniel Phillips
2002-09-10 10:17 ` Roman Zippel
2002-09-11 18:35 ` [RFC] Raceless module interface Daniel Phillips
2002-09-11 18:53 ` Oliver Neukum
2002-09-11 19:20 ` Daniel Phillips
2002-09-11 20:29 ` Oliver Neukum
2002-09-11 21:15 ` Daniel Phillips
2002-09-11 21:26 ` Jamie Lokier
2002-09-11 21:47 ` Daniel Phillips
2002-09-12 1:42 ` Rusty Russell
2002-09-12 2:09 ` Jamie Lokier
2002-09-12 3:13 ` Rusty Russell [this message]
2002-09-12 3:47 ` Daniel Phillips
2002-09-12 3:53 ` Alexander Viro
2002-09-12 4:11 ` Daniel Phillips
2002-09-12 4:40 ` Rusty Russell
2002-09-12 5:27 ` Daniel Phillips
2002-09-12 14:46 ` Gerhard Mack
2002-09-13 0:39 ` Rusty Russell
2002-09-13 2:23 ` Daniel Phillips
2002-09-12 5:35 ` Rusty Russell
2002-09-12 4:52 ` Rusty Russell
2002-09-12 5:58 ` Daniel Phillips
2002-09-12 7:00 ` Rusty Russell
2002-09-13 8:18 ` Helge Hafting
2002-09-12 3:32 ` Daniel Phillips
2002-09-12 1:31 ` Rusty Russell
2002-09-12 9:10 ` Oliver Neukum
2002-09-12 11:27 ` Roman Zippel
2002-09-12 13:03 ` Rusty Russell
2002-09-12 13:44 ` Roman Zippel
2002-09-13 1:30 ` Rusty Russell
2002-09-13 2:19 ` Daniel Phillips
2002-09-13 6:51 ` Rusty Russell
2002-09-13 13:34 ` Daniel Phillips
2002-09-13 13:52 ` Thunder from the hill
2002-09-13 14:09 ` Daniel Phillips
2002-09-13 14:33 ` Thunder from the hill
2002-09-13 14:44 ` Daniel Phillips
2002-09-13 14:59 ` Thunder from the hill
2002-09-13 15:17 ` Daniel Phillips
2002-09-13 15:27 ` Thunder from the hill
2002-09-13 15:37 ` Daniel Phillips
2002-09-16 2:17 ` Rusty Russell
2002-09-16 16:13 ` Daniel Phillips
2002-09-16 16:36 ` Understanding the Principles of Argumentation #3 Daniel Phillips
2002-09-16 16:42 ` Robinson Maureira Castillo
2002-09-16 17:29 ` Cort Dougan
2002-09-16 22:31 ` David Woodhouse
2002-10-01 14:13 ` Daniel Phillips
2002-10-01 14:27 ` David Woodhouse
2002-09-13 15:59 ` [RFC] Raceless module interface Daniel Phillips
2002-09-13 3:14 ` David Gibson
2002-09-13 10:35 ` Roman Zippel
2002-09-13 13:53 ` Daniel Phillips
2002-09-13 15:13 ` Roman Zippel
2002-09-13 15:30 ` Daniel Phillips
2002-09-13 15:55 ` Roman Zippel
2002-09-13 16:09 ` Daniel Phillips
2002-09-13 16:39 ` Thunder from the hill
2002-09-13 17:12 ` Daniel Phillips
2002-09-16 0:24 ` Bill Davidsen
2002-09-16 1:49 ` Rusty Russell
2002-09-16 21:36 ` Roman Zippel
2002-09-16 21:48 ` Daniel Phillips
2002-09-16 22:44 ` Roman Zippel
2002-09-11 15:28 ` Question about pseudo filesystems Bill Davidsen
2002-09-11 19:36 ` Daniel Phillips
2002-09-09 20:12 ` Daniel Phillips
2002-09-09 22:56 ` Jamie Lokier
2002-09-10 1:39 ` Alexander Viro
2002-09-09 20:18 ` Daniel Phillips
2002-09-10 6:48 ` Kai Henningsen
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=20020912031345.760A32C061@lists.samba.org \
--to=rusty@rustcorp.com.au \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=lk@tantalophile.demon.co.uk \
--cc=oliver@neukum.name \
--cc=phillips@arcor.de \
--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;
as well as URLs for NNTP newsgroup(s).