On Fri, Mar 14, 2014 at 12:26:15PM -0400, Mike Snitzer wrote:
> On Fri, Mar 14 2014 at 12:21pm -0400,
> Mike Snitzer wrote:
>
> > I have no problem with this patch, added safety-net and all, but
> > bottomline: if scsi_dh interfaces were being called against a DM
> > multipath request_queue that
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 avoi
On Fri, Mar 14 2014 at 12:21pm -0400,
Mike Snitzer wrote:
> I have no problem with this patch, added safety-net and all, but
> bottomline: if scsi_dh interfaces were being called against a DM
> multipath request_queue that is a bug.
Sorry, s/DM multipath request_queue/non-SCSI requeue_queue/
>
On Fri, Mar 14 2014 at 7:15am -0400,
Christoph Hellwig wrote:
> On Fri, Mar 14, 2014 at 12:13:52PM +0100, Hannes Reinecke wrote:
> > Starting multipath on a cciss device will cause a kernel
> > warning to be triggered. Problem is that we're using the
> > ->queuedata field of the request_queue to
On Fri, Mar 14, 2014 at 12:13:52PM +0100, Hannes Reinecke wrote:
> Starting multipath on a cciss device will cause a kernel
> warning to be triggered. Problem is that we're using the
> ->queuedata field of the request_queue to derefence the
> scsi device; however, for other (non-SCSI) devices this
Starting multipath on a cciss device will cause a kernel
warning to be triggered. Problem is that we're using the
->queuedata field of the request_queue to derefence the
scsi device; however, for other (non-SCSI) devices this
points to a totally different structure.
So we should rather be using acc
6 matches
Mail list logo
