Looks like request_module() has quite a few problems:
* there is no way to distinguish between failing modprobe and successful
one followed by rmmod -a (e.g. called by cron). For one thing, we
don't pass exit value of modprobe to caller of request_module().
* even if we would pass it, obvious attempt to cope with rmmod -a races
fails. I.e. something like
while (object doesn't exist) {
if (request_module(module_name) < 0)
break;
}
would screw up for something like
mount -t floppy <whatever>
since we would happily load floppy.o and look for fs type called "floppy".
And keep doing that forever, since floppy.o doesn't define any fs.
* we could try to protect against rmmod -a by changing semantics of module
syscalls and modprobe(8). Namely, let modprobe called by request_module()
pin the module(s) down and make request_module() (actually its caller)
decrement refcounts. That would solve the problem, but we get another one:
how to find all modules pulled in by modprobe(8) and its children.
Notice that argument of request_module() doesn't help at all - it can have
nothing to name of module we load (block-major-2 -> floppy) and we could have
other modules grabbed by the same modprobe.
* we might try to pull the following trick: in sys_create_module() follow
->parent until we step on request_module()-spawned task. Then put the new
module on a list for that instance of request_module(). That would solve
the problem, but I'm not too happy about such solution - IMO it's ugly.
However, I don't see anything else...
Comments?
-
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 : Tue Apr 23 2002 - 22:00:34 EST