On Thu, 11 Jul 2002, Roman Zippel wrote:
> > In short, it's close to the truth, but it's not quite there in its current
> > form. Al said as much himself.
>
> He was talking about a generic interface. I stared now long enough at
> that code, could anyone point me to where exactly is there a race in
> the filesystem code??? IMO it's more complex than necessary (because it
> has to work around the problem that unregister can't fail), but it should
> work.
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.
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.
> BTW this example shows also the limitation of the current module
> interface. It's impossible for a module to control itself, whether it can
> be unloaded or not. All code for this must be outside of this module,
> after __MOD_DEC_USE_COUNT() the module must not be touched anymore (so
> this call can't be inside of a module).
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.
/me ponders removing Daniel from killfile and decides that it's not worth
the trouble...
-
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