Re: dm: dm_blk_ioctl(): implement failover for SG_IO on dm-multipath

[Martin Wilck <mwilck@suse.com>]

On Wed, 2021-04-28 at 15:54 -0400, Mike Snitzer wrote:
> 
> Ngh... not loving this at all.  

I'm not surprised :-) I infer from your reply that you acknowledge this
is something that should be done one way or the other, and I'm glad
about that.

> But here is a patch (that I didn't
> compile test) that should be folded in, still have to think about how
> this could be made cleaner in general though.

Thanks, much appreciated.

> Also, dm_sg_io_ioctl should probably be in dm-rq.c (maybe even dm-
> mpath.c!?)
> 
> From: Mike Snitzer <snitzer@redhat.com>
> Date: Wed, 28 Apr 2021 15:03:20 -0400
> Subject: [PATCH] dm: use scsi_result_to_blk_status rather than open-
> coding it
> 
> Other small cleanups/nits.
> 
> BUT the fact that dm.c now #includes <scsi/scsi.h> and <scsi/sg.h>
> leaves a very bitter taste.
> 
> Also, hardcoding the issuing of a "fail_path" message (assumes tgt is
> dm-mpath) but still having checks like !tgt->type->message.. its all
> very contrived and awkward!

This I can explain. I need to check t->type->message because not all
targets define it. If I didn't, yet used message(), the kernel might
crash. I would have avoided the hard-coded "fail_path", too, if I had
found a way to figure out which messages a given target supports, or
whether the target in question is the multipath target in the first
place. But I couldn't figure it out. If it's possible, please tell me
how. 

Wrt "fail_path", the assumption is that other rq-based targets would
either not support "fail_path" and thus return an error, or implement
it with the same semantics as multipath. In both cases, my patch would
do the "right thing" (falling back to standard behavior in the error
case).

Thanks,
Martin