lkml.org 
[lkml]   [2002]   [Sep]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [RFC] Raceless module interface
Date
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:28    [W:0.147 / U:0.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site