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. - 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/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:21 EST