On Tue, Apr 29, 2025 at 06:50:18PM +0200, Kevin Wolf wrote: > Multipath cannot directly provide failover for ioctls in the kernel > because it doesn't know what each ioctl means and which result could > indicate a path error. Userspace generally knows what the ioctl it > issued means and if it might be a path error, but neither does it know > which path the ioctl took nor does it necessarily have the privileges to > fail a path using the control device. > > In order to allow userspace to address this situation, implement a > DM_MPATH_PROBE_PATHS ioctl that prompts the dm-mpath driver to probe all > active paths in the current path group to see whether they still work, > and fail them if not. If this returns success, userspace can retry the > ioctl and expect that the previously hit bad path is now failed (or > working again). > > The immediate motivation for this is the use of SG_IO in QEMU for SCSI > passthrough. Following a failed SG_IO ioctl, QEMU will trigger probing > to ensure that all active paths are actually alive, so that retrying > SG_IO at least has a lower chance of failing due to a path error. > However, the problem is broader than just SG_IO (it affects any ioctl), > and if applications need failover support for other ioctls, the same > probing can be used. > > This is not implemented on the DM control device, but on the DM mpath > block devices, to allow all users who have access to such a block device > to make use of this interface, specifically to implement failover for > ioctls. For the same reason, it is also unprivileged. Its implementation > is effectively just a bunch of reads, which could already be issued by > userspace, just without any guarantee that all the rights paths are > selected. > > The probing implemented here is done fully synchronously path by path; > probing all paths concurrently is left as an improvement for the future. > > Co-developed-by: Hanna Czenczek <hre...@redhat.com> > Signed-off-by: Hanna Czenczek <hre...@redhat.com> > Signed-off-by: Kevin Wolf <kw...@redhat.com>
Reviewed-by: Benjamin Marzinski <bmarz...@redhat.com>
