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

2013-04-26 Thread Mike Snitzer
On Fri, Apr 26 2013 at 2:05am -0400, Hannes Reinecke wrote: > On 04/25/2013 05:31 PM, Mike Snitzer wrote: > > On Thu, Apr 25 2013 at 10:50am -0400, > > Mikulas Patocka wrote: > > > >> > >> > >> On Thu, 25 Apr 2013, Mike Snitzer wrote: > >> > >>> On Thu, Apr 25 2013 at 9:48am -0400, > >>> Miku

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

2013-04-25 Thread Hannes Reinecke
On 04/25/2013 05:31 PM, Mike Snitzer wrote: > On Thu, Apr 25 2013 at 10:50am -0400, > Mikulas Patocka wrote: > >> >> >> On Thu, 25 Apr 2013, Mike Snitzer wrote: >> >>> On Thu, Apr 25 2013 at 9:48am -0400, >>> Mikulas Patocka wrote: >>> On Mon, 22 Apr 2013, Mike Snitzer wrote: >>>

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

2013-04-25 Thread Bryn M. Reeves
On 04/25/2013 04:37 PM, Mike Snitzer wrote:> clariion_match does more than check the vendor and product; if tpgs is > set (ALUA mode) it returns false. > > So yes, while there is room for improvement in clariion_match the > current code should work just fine with reasoning between emc and alua.

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

2013-04-25 Thread Mike Snitzer
On Thu, Apr 25 2013 at 11:27am -0400, Bryn M. Reeves wrote: > On 04/25/2013 03:50 PM, Mikulas Patocka wrote: > >On Thu, 25 Apr 2013, Mike Snitzer wrote: > >>The handler that is automatically attached _should_ be the correct > >>handler. We now have the .match() hook for scsi_dh and it has made f

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

2013-04-25 Thread Mike Snitzer
On Thu, Apr 25 2013 at 10:50am -0400, Mikulas Patocka wrote: > > > On Thu, 25 Apr 2013, Mike Snitzer wrote: > > > On Thu, Apr 25 2013 at 9:48am -0400, > > Mikulas Patocka wrote: > > > > > > > > > > > On Mon, 22 Apr 2013, Mike Snitzer wrote: > > > > > > > I spoke with Hannes at LSF, to ad

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

2013-04-25 Thread Bryn M. Reeves
On 04/25/2013 03:50 PM, Mikulas Patocka wrote: On Thu, 25 Apr 2013, Mike Snitzer wrote: 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. The EMC devices

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

2013-04-25 Thread Mikulas Patocka
On Thu, 25 Apr 2013, Mike Snitzer wrote: > On Thu, Apr 25 2013 at 9:48am -0400, > Mikulas Patocka 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

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

2013-04-25 Thread Mike Snitzer
On Thu, Apr 25 2013 at 9:48am -0400, Mikulas Patocka 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 kr

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

2013-04-25 Thread Mikulas Patocka
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 th

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

2013-04-22 Thread Mike Snitzer
On Mon, Apr 08 2013 at 5:50pm -0400, Mike Snitzer wrote: > Preallocate scsi_dh_data using scsi_dh_alloc_data() during table load > but attach the scsi_dh for each path during table resume. This avoids a > kernel crash that can happen when changing the scsi_dh during table > load. > > When we r

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

2013-04-08 Thread Mike Snitzer
Preallocate scsi_dh_data using scsi_dh_alloc_data() during table load but attach the scsi_dh for each path during table resume. This avoids a kernel crash that can happen when changing the scsi_dh during table load. When we reload a multipath device, there are two instances of the multipath targe