Isn't the real problem here that we've got a "rogue" running around
removing things that we might be about to use?
Yes, I think that request_module() should indicate to the caller if
something "suitable" was found. But I think having rmmod -a running around
sweeping things randomly is bad.
Perhaps what we need is a way to tell _how_long_ago_ the count on a module
last changed. Thus, rmmod -a could decide to only remove modules that were
last used more than an hour ago, or somesuch. Push the policy question into
userspace.
Matt
On Mon, Apr 22, 2002 at 08:49:40PM -0400, Alexander Viro wrote:
> 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/
-- Matthew Dharm Home: mdharm-usb@one-eyed-alien.net Maintainer, Linux USB Mass Storage DriverYOU SEE!!?? It's like being born with only one nipple! -- Erwin User Friendly, 10/19/1998
This archive was generated by hypermail 2b29 : Tue Apr 23 2002 - 22:00:34 EST