From: Benjamin Marzinski <bmarzins@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: dm-devel@lists.linux.dev, hreitz@redhat.com, mpatocka@redhat.com,
snitzer@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] dm mpath: Interface for explicit probing of active paths
Date: Tue, 29 Apr 2025 19:22:39 -0400 [thread overview]
Message-ID: <aBFfP-XaHHAs4vE_@redhat.com> (raw)
In-Reply-To: <20250429165018.112999-3-kwolf@redhat.com>
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 <hreitz@redhat.com>
> Signed-off-by: Hanna Czenczek <hreitz@redhat.com>
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Benjamin Marzinski <bmarzins@redhat.com>
next prev parent reply other threads:[~2025-04-29 23:22 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 16:50 [PATCH 0/2] dm mpath: Interface for explicit probing of active paths Kevin Wolf
2025-04-29 16:50 ` [PATCH 1/2] dm: Allow .prepare_ioctl to handle ioctls directly Kevin Wolf
2025-04-29 23:22 ` Benjamin Marzinski
2025-05-08 13:50 ` Martin Wilck
2025-04-29 16:50 ` [PATCH 2/2] dm mpath: Interface for explicit probing of active paths Kevin Wolf
2025-04-29 23:22 ` Benjamin Marzinski [this message]
2025-05-08 13:51 ` [PATCH 0/2] " Martin Wilck
2025-05-12 13:46 ` Mikulas Patocka
2025-05-13 7:06 ` Martin Wilck
2025-05-12 15:18 ` Kevin Wolf
2025-05-13 5:55 ` Christoph Hellwig
2025-05-13 6:09 ` Hannes Reinecke
2025-05-13 6:14 ` Christoph Hellwig
2025-05-13 6:32 ` Hannes Reinecke
2025-05-13 6:49 ` Christoph Hellwig
2025-05-13 8:17 ` Martin Wilck
2025-05-14 4:53 ` Christoph Hellwig
2025-05-15 11:14 ` Paolo Bonzini
2025-05-13 16:29 ` Benjamin Marzinski
2025-05-14 4:56 ` Christoph Hellwig
2025-05-14 6:39 ` Hannes Reinecke
2025-05-14 16:01 ` Benjamin Marzinski
2025-05-16 5:52 ` Christoph Hellwig
2025-05-13 9:29 ` Kevin Wolf
2025-05-13 15:43 ` Paolo Bonzini
2025-05-14 4:57 ` Christoph Hellwig
2025-05-14 16:23 ` Benjamin Marzinski
2025-05-14 17:37 ` Martin Wilck
2025-05-15 2:53 ` Paolo Bonzini
2025-05-15 10:34 ` Martin Wilck
2025-05-15 10:51 ` Paolo Bonzini
2025-05-15 14:50 ` Martin Wilck
2025-05-15 14:29 ` Benjamin Marzinski
2025-05-15 15:00 ` Martin Wilck
2025-05-16 5:57 ` Christoph Hellwig
2025-05-13 6:30 ` Hannes Reinecke
2025-05-13 18:09 ` Benjamin Marzinski
2025-05-13 8:00 ` Martin Wilck
2025-05-13 10:06 ` Martin Wilck
2025-05-14 21:21 ` Martin Wilck
2025-05-15 10:11 ` Kevin Wolf
2025-05-15 11:09 ` Paolo Bonzini
2025-05-15 15:18 ` Martin Wilck
2025-05-15 15:05 ` Martin Wilck
2025-05-16 6:00 ` Christoph Hellwig
2025-05-16 16:06 ` Benjamin Marzinski
2025-05-19 5:32 ` Christoph Hellwig
2025-05-19 18:24 ` Benjamin Marzinski
2025-05-28 20:44 ` Martin Wilck
2025-05-19 10:06 ` Kevin Wolf
2025-05-19 17:33 ` Martin Wilck
2025-05-20 13:46 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBFfP-XaHHAs4vE_@redhat.com \
--to=bmarzins@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpatocka@redhat.com \
--cc=snitzer@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.