Re: [RFC] race in request_module()

[Matthew Dharm <mdharm-kernel@one-eyed-alien.net>]

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

The question then becomes one of how do I distinguish a race condition from
a legitimate load/unload cycle?

I'm not certain that I see a way.  Unless we mark modules as "not used
yet", until the first piece of code in them is used.  But that feels like
an ugly hack, and seems likely to be problematic for some unusual
scenarios.

It looks like we might need another state for modules to be in.  Or simply
discourage people from auto-unloading "unused" modules.

I've seen this on usb-storage also, where the module count is maintained by
the SCSI layers -- it's only non-zero when someone/something is actively
using a device, which means that it will tend to get unloaded by an rmmod
-a if we're between CD burns, for example.  And, when the module is
unloaded, all sorts of state information is lost.  rmmod -a is my enemy in
this case.

Isn't the problem here just the misuse of rmmod -a?  Perhaps we should
attach a warning to the documentation to indicate the possible badness that
can happen.

Matt

On Mon, Apr 22, 2002 at 09:05:56PM -0400, Alexander Viro wrote:
> 
> 
> On Mon, 22 Apr 2002, Matthew Dharm wrote:
> 
> > 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.
> 
> Still doesn't solve the problem.  And BTW, there are userland races of
> similar kind - foo.o depends on bar.o, modprobe loads bar.o, goes to look
> for foo.o and gets bar.o removed from under it.
> 
> The thing being, relying on time doesn't help - e.g. we might have modules
> on automounted volume and delays may be really long if the thing happens
> at time when load is high.

-- 
Matthew Dharm                              Home: mdharm-usb@one-eyed-alien.net 
Maintainer, Linux USB Mass Storage Driver

I'm just trying to think of a way to say "up yours" without getting fired.
					-- Stef
User Friendly, 10/8/1998

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]