Hi,
On Thu, 11 Jul 2002, Alexander Viro wrote:
> 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.
In the load path there are more races. Read access to the module list is
only protected by the BKL. This makes it possible to create multiple
modules with the same name in sys_create_module (module_map() can sleep).
> 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.
normal cases or simple cases? The filesystem interface is a very simple
one, now e.g. add a proc interface to it. The current module interface
requires that any first reference to a module must be protected against
module load/unload and unregister, what requires two locks. It could be
reduced to a single lock, if the module was allowed to let the unload
fail, because there are still users. The module actually knows best,
whether there are still references to the module, but it can't tell that
the kernel.
bye, Roman
-
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:22 EST