Re: Kernel bug triggered in multipath

[Christoph Hellwig <hch@infradead.org>]

On Fri, Mar 14, 2014 at 12:21:11PM -0400, Mike Snitzer wrote:
> DM multipath has a role in insuring the desired scsi_dh is attached and
> that it holds a reference on the attached scsi_dh.
> 
> I'm open to ideas of how dm-multipath could avoid having _any_ role here
> but it isn't so simple to avoid, dm-multipath does 3 things in this
> area (ranging from lightest to heaviest relative to scsi_dh interface use):
> 1) get reference on scsi_dh that is already attached -- most widely used
>    now that the scsi_dh matching code has been improved to get correct
>    scsi_dh attached during scsi device scan)
> 2) no scsi_dh was attached, but one should be -- really shouldn't happen
>    anymore
> 3) switch from the scsi_dh that was auto-attached by scsi_dh matching to
>    some user-specified override -- shouldn't be needed now but a user may
>    have a custom scsi_dh they've developed.

What we currently have surely is a bit of a layering violation.  I don't
think it's urgent or overly important to fix it now, but I see two ways
out:

 a) move the handler registration to dm-multipath.  This still leaves
 the problem on figuring out if a handler supports a device, but at
 least that problem is inside the handlers now.
 b) move the path selectors to the block layer, and have the methods
 provided indirect off the requeuest_queue

b) seems like the cleanest layering, although in the case of SCSI (the
only one that matters at the moment) that would give us a double
indirection.