| Message ID | 20210611202509.5426-1-mwilck@suse.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | dm: dm_blk_ioctl(): implement failover for SG_IO on dm-multipath | expand |
On Fri, Jun 11 2021 at 4:25P -0400, mwilck@suse.com <mwilck@suse.com> wrote: > From: Martin Wilck <mwilck@suse.com> > > Hello Mike, > > here is v3 of my attempt to add retry logic to SG_IO on dm-multipath devices. > Sorry that it took such a long time. > > Regards > Martin > > Changes v2->v3: > > - un-inlined scsi_result_to_blk_status again, and move the helper > __scsi_result_to_blk_status to block/scsi_ioctl.c instead > (Bart v. Assche) > - open-coded the status/msg/host/driver-byte -> result conversion > where the standard SCSI helpers aren't usable (Bart v. Assche) This work offers a proof-of-concept but it needs further refinement for sure. The proposed open-coded SCSI code (in patch 2's drivers/md/dm-scsi_ioctl.c) is well beyond what I'm willing to take in DM. If this type of functionality is still needed (for kvm's SCSI passthru snafu) then more work is needed to negotiate proper interfaces with the SCSI subsystem (added linux-scsi to cc, odd they weren't engaged on this). Does it make sense to extend the SCSI device handler interface to add the required enablement? (I think it'd have to if this line of work is to ultimately get upstream). Mike > Changes v1->v2: > > - applied modifications from Mike Snitzer > - moved SG_IO dependent code to a separate file, no scsi includes in > dm.c any more > - made the new code depend on a configuration option > - separated out scsi changes, made scsi_result_to_blk_status() > inline to avoid dependency of dm_mod from scsi_mod (Paolo Bonzini) > > Martin Wilck (2): > scsi: export __scsi_result_to_blk_status() in scsi_ioctl.c > dm: add CONFIG_DM_MULTIPATH_SG_IO - failover for SG_IO on dm-multipath > > block/scsi_ioctl.c | 52 ++++++++++++++- > drivers/md/Kconfig | 11 ++++ > drivers/md/Makefile | 4 ++ > drivers/md/dm-core.h | 5 ++ > drivers/md/dm-rq.h | 11 ++++ > drivers/md/dm-scsi_ioctl.c | 127 +++++++++++++++++++++++++++++++++++++ > drivers/md/dm.c | 20 +++++- > drivers/scsi/scsi_lib.c | 29 +-------- > include/linux/blkdev.h | 3 + > 9 files changed, 229 insertions(+), 33 deletions(-) > create mode 100644 drivers/md/dm-scsi_ioctl.c > > -- > 2.31.1 > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
Hi Mike, On Mo, 2021-06-14 at 11:15 -0400, Mike Snitzer wrote: > > This work offers a proof-of-concept but it needs further refinement > for sure. Thanks for looking into it again. I need some more guidance from your part in order to be able to resubmit the set in a form that you consider ready for merging. > The proposed open-coded SCSI code (in patch 2's drivers/md/dm- > scsi_ioctl.c) > is well beyond what I'm willing to take in DM. I'm not sure what code you're referring to. Is it the processing of the bytes of the SCSI result code? If yes, please note that I had changed that to open-coded form in response to Bart's review of my v2 submission. If it's something else, please point it out to me. To minimize the special-casing for this code path, Hannes suggested to use a target-specific unprepare_ioctl() callback to to tell the generic dm code whether a given ioctl could be retried. The logic that I've put into dm-scsi_ioctl.c could then be moved into the unprepare_ioctl() callback of dm-mpath. dm_blk_ioctl() would need to check the callback's return value and possibly retry the ioctl. Would hat appeal to you? > If this type of > functionality is still needed (for kvm's SCSI passthru snafu) then > more work is needed to negotiate proper interfaces with the SCSI > subsystem (added linux-scsi to cc, odd they weren't engaged on this). Not cc'ing linux-scsi was my oversight, sorry about that. But I don't quite understand what interfaces you have in mind. SCSI needs to expose the SG_IO interface to dm, which it does; I just needed to export sg_io() to get access to the sg_io_hdr fields. The question whether a given IO can be retried is decided on the dm (-mpath) layer, based on blk_status_t; no additional interface on the SCSI side is necessary for that. > Does it make sense to extend the SCSI device handler interface to add > the required enablement? (I think it'd have to if this line of work > is > to ultimately get upstream). My current code uses the device handler indirectly for activating paths during priority group switching, via the dm-mpath prepare_ioctl() method and __pg_init_all_paths(). This is what I intended - to use exactly the same logic for SG_IO which is used for regular read/write IO on the block device. What additional functionality for the device handler do you have in mind? Regards and thanks, Martin > > Mike > > > > Changes v1->v2: > > > > - applied modifications from Mike Snitzer > > - moved SG_IO dependent code to a separate file, no scsi includes > > in > > dm.c any more > > - made the new code depend on a configuration option > > - separated out scsi changes, made scsi_result_to_blk_status() > > inline to avoid dependency of dm_mod from scsi_mod (Paolo > > Bonzini) > > > > Martin Wilck (2): > > scsi: export __scsi_result_to_blk_status() in scsi_ioctl.c > > dm: add CONFIG_DM_MULTIPATH_SG_IO - failover for SG_IO on dm- > > multipath > > > > block/scsi_ioctl.c | 52 ++++++++++++++- > > drivers/md/Kconfig | 11 ++++ > > drivers/md/Makefile | 4 ++ > > drivers/md/dm-core.h | 5 ++ > > drivers/md/dm-rq.h | 11 ++++ > > drivers/md/dm-scsi_ioctl.c | 127 > > +++++++++++++++++++++++++++++++++++++ > > drivers/md/dm.c | 20 +++++- > > drivers/scsi/scsi_lib.c | 29 +-------- > > include/linux/blkdev.h | 3 + > > 9 files changed, 229 insertions(+), 33 deletions(-) > > create mode 100644 drivers/md/dm-scsi_ioctl.c > > > > -- > > 2.31.1 > > > -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
On Tue, Jun 15 2021 at 6:54P -0400, Martin Wilck <mwilck@suse.com> wrote: > Hi Mike, > > On Mo, 2021-06-14 at 11:15 -0400, Mike Snitzer wrote: > > > > This work offers a proof-of-concept but it needs further refinement > > for sure. > > Thanks for looking into it again. I need some more guidance from your > part in order to be able to resubmit the set in a form that you > consider ready for merging. > > > The proposed open-coded SCSI code (in patch 2's drivers/md/dm- > > scsi_ioctl.c) > > is well beyond what I'm willing to take in DM. > > I'm not sure what code you're referring to. Is it the processing of the > bytes of the SCSI result code? If yes, please note that I had changed > that to open-coded form in response to Bart's review of my v2 > submission. If it's something else, please point it out to me. > > To minimize the special-casing for this code path, Hannes suggested to > use a target-specific unprepare_ioctl() callback to to tell the generic > dm code whether a given ioctl could be retried. The logic that I've put > into dm-scsi_ioctl.c could then be moved into the unprepare_ioctl() > callback of dm-mpath. dm_blk_ioctl() would need to check the callback's > return value and possibly retry the ioctl. Would hat appeal to you? > > > If this type of > > functionality is still needed (for kvm's SCSI passthru snafu) then > > more work is needed to negotiate proper interfaces with the SCSI > > subsystem (added linux-scsi to cc, odd they weren't engaged on this). > > Not cc'ing linux-scsi was my oversight, sorry about that. > > But I don't quite understand what interfaces you have in mind. SCSI > needs to expose the SG_IO interface to dm, which it does; I just needed > to export sg_io() to get access to the sg_io_hdr fields. The question > whether a given IO can be retried is decided on the dm (-mpath) layer, > based on blk_status_t; no additional interface on the SCSI side is > necessary for that. > > > Does it make sense to extend the SCSI device handler interface to add > > the required enablement? (I think it'd have to if this line of work > > is > > to ultimately get upstream). > > My current code uses the device handler indirectly for activating paths > during priority group switching, via the dm-mpath prepare_ioctl() > method and __pg_init_all_paths(). This is what I intended - to use > exactly the same logic for SG_IO which is used for regular read/write > IO on the block device. What additional functionality for the device > handler do you have in mind? > > Regards and thanks, > Martin I just replied to patch 2 with detailed suggestions. Thanks, Mike -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
From: Martin Wilck <mwilck@suse.com> Hello Mike, here is v3 of my attempt to add retry logic to SG_IO on dm-multipath devices. Sorry that it took such a long time. Regards Martin Changes v2->v3: - un-inlined scsi_result_to_blk_status again, and move the helper __scsi_result_to_blk_status to block/scsi_ioctl.c instead (Bart v. Assche) - open-coded the status/msg/host/driver-byte -> result conversion where the standard SCSI helpers aren't usable (Bart v. Assche) Changes v1->v2: - applied modifications from Mike Snitzer - moved SG_IO dependent code to a separate file, no scsi includes in dm.c any more - made the new code depend on a configuration option - separated out scsi changes, made scsi_result_to_blk_status() inline to avoid dependency of dm_mod from scsi_mod (Paolo Bonzini) Martin Wilck (2): scsi: export __scsi_result_to_blk_status() in scsi_ioctl.c dm: add CONFIG_DM_MULTIPATH_SG_IO - failover for SG_IO on dm-multipath block/scsi_ioctl.c | 52 ++++++++++++++- drivers/md/Kconfig | 11 ++++ drivers/md/Makefile | 4 ++ drivers/md/dm-core.h | 5 ++ drivers/md/dm-rq.h | 11 ++++ drivers/md/dm-scsi_ioctl.c | 127 +++++++++++++++++++++++++++++++++++++ drivers/md/dm.c | 20 +++++- drivers/scsi/scsi_lib.c | 29 +-------- include/linux/blkdev.h | 3 + 9 files changed, 229 insertions(+), 33 deletions(-) create mode 100644 drivers/md/dm-scsi_ioctl.c