[dm-devel] [PATCH 2/2] dm mpath: attach scsi_dh during table resume

[Mike Snitzer]

On Thu, Apr 25 2013 at  9:48am -0400,
Mikulas Patocka <mpatocka at redhat.com> wrote:

> 
> 
> On Mon, 22 Apr 2013, Mike Snitzer wrote:
> 
> > I spoke with Hannes at LSF, to address the potential crashes in the
> > endio path (e.g. stpg_endio) we'd have to bump the scsi_dh_data kref
> > where appropriate (e.g. for ALUA kref_get in submit_stpg and kref_put in
> > stpg_endio).
> > 
> > But that is just the tip of the iceberg relative to scsi_dh lifetime.
> > Seems we've been playing it pretty fast and loose with scsi_dh issued
> > requests vs detach for quite some time.
> > 
> > I'm now inclined to not care about this issue.  Take away is: don't
> > switch the device handler (attach the correct one from the start).
> 
> I did a patch that disables device handler switching and it was NACKed by 
> Hannes. The problem that he pointed out was - when we load SCSI device 
> handler modules, they attach automatically to SCSI devices they think they 
> belong to. The user then can't set the desired device handler in multipath 
> configuration because a different handler is already attached.

The handler that is automatically attached _should_ be the correct
handler.  We now have the .match() hook for scsi_dh and it has made for
reliable scsi_dh attachment of the correct handler.
 
> So we need a functionality to change device handlers.

I really cannot think of a sequence where the scsi_dh .match() will
attach the incorrect handler.  This is why I added the
"retain_attached_hw_handler" feature to mpath (commit a58a935d5).

> (or maybe stop the scsi device handlers from attaching automatically, but 
> it would surely generate a lot of other regressions)

The need to support changing device handlers (via multipath table load)
is overblown/historic.