Re: Bugs in multipath scsi in 4.3-rc2

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Fri, 2015-10-02 at 14:56 +0200, Christoph Hellwig wrote:
> On Wed, Sep 30, 2015 at 03:34:54PM -0700, James Bottomley wrote:
> > Perhaps we don't have to be that draconian.  There's no real reason we
> > can't autoload asynchronously.  If the module isn't ready by the time we
> > come to check the attachment, then it will attach to the device later
> > when the module init routine runs.
> 
> I don't think this works.  We're attaching just after the request_module
> call, so modprobe doesn't really have a chance to finish before we
> return.

Yes, I suspect it will mostly happen in the alua attach, except for
large LUN sets.

> > Should we do anything to limit the module_request floods?  This will
> > likely happen for every LUN of an ALUA system ... there can be hundreds
> > of those.
> 
> Once the alua module is loaded there won't be any request_module calls.
> If you build with device handler support but without ALUA support
> you'll get a lot of calls, but that's not any different than probing
> for other optional features.

That doesn't matter: if you modprobe alua after all devices are
discovered, it will attach correctly to all potential devices from the
alua module_init.  This means the effect is the same whether the
request_module is sync or async ... the object is to get the device
attached to alua if it is an alua device.

The only drawback of an async request_module is that we get a flood of
request_modules()s from every LUN on an array until alua is loaded.

> Personally I think we probably should simple build ALUA support into
> scsi_mod if SCSI_DH is selected, as that's part of the standard and
> supported by any modern multi pathing device.

I suppose; the code size is roughly the same as scsi_dh.o which we just
made non modular.

James