From: Daniel Phillips <phillips@arcor.de>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: lk@tantalophile.demon.co.uk, oliver@neukum.name,
zippel@linux-m68k.org, viro@math.psu.edu, kaos@ocs.com.au,
linux-kernel@vger.kernel.org
Subject: Re: [RFC] Raceless module interface
Date: Thu, 12 Sep 2002 07:58:02 +0200 [thread overview]
Message-ID: <E17pMzL-0007fx-00@starship> (raw)
In-Reply-To: <20020912145244.4cc6fb98.rusty@rustcorp.com.au>
On Thursday 12 September 2002 06:52, Rusty Russell wrote:
> On Thu, 12 Sep 2002 05:47:57 +0200
> Daniel Phillips <phillips@arcor.de> wrote:
>
> > On Thursday 12 September 2002 05:13, Rusty Russell wrote:
> > > 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.
> >
> > No we are not. The module remains in the 'stopped' state
> > throughout the entire initialization process, as it should and
> > does, in my model.
>
> Um, so register_xxx interfaces all use try_inc_mod_count (ie. a
> struct module * extra arg to register_xxx)?
In that case they are filesystems or some other thing that fits the
model closely enough for try_ind_mod_count to be efficient. This
case is easy and solved as far as I'm concerned, do correct me if
I'm wrong. Assuming I'm not wrong, on to a hard and interesting
case.
> Or those entry points
> are not protected by try_inc_mod_count, so it must bump the refcnt, so
> you need to sleep in load until the module becomes unused again.
Let's consider LSM as a really hard case, and let's suppose that the
register_*'s just plug new functions into function tables. These functions
are just called indirectly, there is no module entry/exit accounting
whatsoever, except that the inc/dec rule must be followed where module code
itself might sleep.
Anyway, at the -EBARF point, all the function pointers have been restored to
their original state, but we may have some tasks executing in the module
already, which got in while _xxx was there. The solution is to do the
magic_wait_for_quiescence (yes I know it has a real name, I forgot it) before
returning -EBARF. Refcounts never come into it.
What did I miss? It was too easy.
Ah, I'm glossing over how the "I need to sleep" intramodule refcounts
interact with the magic quiescence test. Let's see if some sleep fixes that.
I doubt this is any central issue though. We could, for instance, pass the
address of the count variable to the quiescence tester, and it will be
examined at schedule time, however that works (I promise to find out soon).
> You have the same issue in the "wait for schedule" case on unload,
> where someone jumps in while you are unregistering.
We don't. Our LSM module will first restore all the function pointers to
their original state, then wait for everyone to schedule.
> My implementation
> decided to ignore this problem (ie. potentially wait forever with the
> module half-loaded) but it is an issue.
I don't see the endless wait. It looks to me like it's just the time
required for everyone to schedule, which is unbounded all right, but not in
any interesting sense.
--
Daniel
next prev parent reply other threads:[~2002-09-12 5:51 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
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 [this message]
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=E17pMzL-0007fx-00@starship \
--to=phillips@arcor.de \
--cc=kaos@ocs.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=lk@tantalophile.demon.co.uk \
--cc=oliver@neukum.name \
--cc=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;
as well as URLs for NNTP newsgroup(s).