Re: [PATCH 1/3] scsi_dh: Add modalias support for SCSI targets

[Chandra Seetharaman <sekharan@us.ibm.com>]

Hi Kay,

Thanks for looking into this.

On Tue, 2009-04-07 at 22:15 -0700, Kay Sievers wrote:
> On Tue, Apr 7, 2009 at 16:50, Chandra Seetharaman <sekharan@us.ibm.com> wrote:
> > On Wed, 2009-04-08 at 01:22 +0200, Hannes Reinecke wrote:
> >> On Fri, Apr 03, 2009 at 03:43:10PM -0700, Chandra Seetharaman wrote:
> 
> >> > If not, Can you accept the patches, please.
> >> >
> >> The problem here is that module autoloading doesn't work for
> >> device_handler. We have to have the callbacks in place _before_
> >> driver probing starts as we might need to intercept the I/O
> >> requests and/or errors. When using modalias the module loading
> >> will be too late and the hooks will only be established after
> >> the probing has already happened.
> >> (The module autoloading is an asynchronous call in device_add(),
> >> where we don't write for it to succeed. So probing will continue
> >> and we woulnd't have the callbacks in place when probing
> >> starts).
> >
> > Your analysis is correct.
> >
> > But, the chicken-n-egg problem you described exists only for the first
> > device that is probed, module will be in place for the other devices.
> >
> > The first device race is handled by acting on the bus notification for
> > the BUS_NOTIFY_BOUND_DRIVER event (patch 3/3 in my patch list).
> 
> How do you make sure, that the module is initialized when the
> BOUND_DRIVER event is happening? The userspace process loading the
> module can take any time to load, and I don't see how that is handled.
> Care to explain that in detail?

Sure.

Currently, when a scsi_dh (like scsi_dh_rdac) module is insmodded, it
sets up a notification for BUS_NOTIFY_ADD_DEVICE, and will walk thru the
bus list and attach all the devices that _are_ already configured.

With the attached patches, there are three ways that a device
can get attached to the module.
 1 scanning of the bus list by the module, if the module is inserted
   after the device is configured.
 2 by handling NOTIFY_ADD_DEVICE by the module, if the device comes
   after the module is inserted.
 3 the third case, which is the race Hannes mentioned, which is 
   mostly w.r.t the device that initiates this modalias chain of
   events, is that the device is past the NOTIFY_ADD_DEVICE point
   in the device configuration path and is still not completely 
   configured hence it is not in the bus_list (so 1 and 2 will 
   miss this). This device will be caught the BOUND_DEVICE
   notification which is just before adding the device to the 
   bus list in the device configuration path.

Hope it is clear now.
> 
> I guess, you either need to implement a "device scan" from the module
> loading routine to find all currently unhandled devices, or you need

We do that currently (without these patches) in scsi_dh. But the problem
is how do we get the module in place.

> to issue a blocking request_module() from inside the kernel and try to
> find a matching module, and then run the find again. The modalias

You mean call request_module() during device configuration ? Even if we
do that, we will not find the same devices again if we probe, so we will
have the same issue as we have in hand as of now. So not much of an
improvement.

> seems not like the right solution here.
> 
> Thanks,
> Kay