Re: Why /dev/sdc1 doesn't show up...

[Doug Ledford <dledford@redhat.com>]

On Tue, Nov 19, 2002 at 04:52:25PM +1100, Rusty Russell wrote:
> > right).  Or you can run a notifier on "enlivening" a module: I'd hoped
> > to avoid that.
> 
> Actually, after some thought, this seems to clearly be the Right
> Thing, because it solves another existing race.  Consider a module
> which does:
> 
> 	if (!register_foo(&my_foo))
> 		goto cleanup;
> 	if (!create_proc_entry(&my_entry))
> 		goto cleanup_foo;

There is *NO* module that does this right now and can be considered even 
close to working.  The rule always has been "register yourself when you 
are ready for use".  You're trying to add this new "You can fail after 
registering yourself" semantic for brain dead coders that can't write an 
init function to save thier ass.  My position is that in doing so, you 
fuck all of us that do write a reasonable init sequence and handle our 
error conditions.  Plus, since this is a changes in semantics, you have 
possibly 50 or 100 modules that rely on the old behaviour, and maybe a few 
that are broken in regards to registration ordering.  I think you are 
trying to fix the wrong group of modules here.

So, to me, the answer is clear.  The rule is hard and fast, you don't hand 
out your function pointers to other modules or the core kernel until you 
are ready for them to be used.  Don't muck with the module loader to solve 
the problem, fix the maybe 4 or 5 modules that might violate this rule.

> If register_foo() calls /sbin/hotplug, the module can still fail to
> load and /sbin/hotplug is called for something that doesn't exist.

Which is just totally fucking stupid on the part of any module author that 
would do things in that order.  You're trying to write a module loader 
that makes it safe for a module author to be a total moron.  Don't.  Let 
the morons go code somewhere else.  For the kernel, make them follow a few 
sensible rules instead of enforcing moron proof crap on everyone else.

> With the new module loader, you can also have /sbin/hotplug try to
> access the module before it's gone live, which will fail to prevent
> the "using before we know module won't fail init" race.
> 
> Now, if you run /sbin/hotplug out of a notifier which is fired when
> the module actually goes live, this problem vanishes.  It also means
> we can block module unload until /sbin/hotplug is run.
> 
> The part that makes this feel like the Right Thing is that adding to
> init/main.c:
> 
> 	/* THIS_MODULE == NULL */
> 	notifier_call_chain(&module_notifiers, MODULE_LIVE, NULL);
> 
> means that /sbin/hotplug is called for everything which was registered
> at boot.  (We may not want to do this, but in general the symmetry
> seems really nice).
> 
> [ Note: the logic for /sbin/hotplug applies to any similar "publicity"
>   function which promises that something now exists. ]
> 
> Al, thoughts?

I actually like the idea of having an automatic go live function that we 
can trigger, but I still don't think that justifies blocking a module from 
entering itself during init.

-- 
  Doug Ledford <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606