On Thu, Apr 25 2013 at 9:48am -0400, Mikulas Patocka <mpatocka@xxxxxxxxxx> 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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
