Message-ID: <CABgObfaEiMN=YANk02EWini+jAXU1MxSvo8_jYWaMiu3ds7hgQ@mail.gmail.com>
Date: Thu, 15 May 2025 04:53:38 +0200
From: Paolo Bonzini <pbonzini@...hat.com>
To: Martin Wilck <mwilck@...e.com>
Cc: Benjamin Marzinski <bmarzins@...hat.com>, Christoph Hellwig <hch@...radead.org>, 
	Kevin Wolf <kwolf@...hat.com>, dm-devel@...ts.linux.dev, 
	Hanna Czenczek <hreitz@...hat.com>, Mikulas Patocka <mpatocka@...hat.com>, snitzer@...nel.org, 
	"Kernel Mailing List, Linux" <linux-kernel@...r.kernel.org>, Hannes Reinecke <hare@...e.com>
Subject: Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active paths

Il mer 14 mag 2025, 13:37 Martin Wilck <mwilck@...e.com> ha scritto:
>
> I'd go one step further. Christoph is right to say that what we're
> currently doing in qemu – passing through every command except the
> PRIN/PROUT to a multipath device – is a dangerous thing to do.
>
> Passthrough from a dm-multipath device to a SCSI device makes sense
> only for a small subset of the SCSI command set. Basically just for the
> regular IO commands like the various READ and WRITE variants and the
> occasional UNMAP. The fact that customers
> have been running these setups in large deployments over many years
> suggests that, if other commands ever get passed through to member
> devices, it has rarely had fatal consequences.
>
> Nobody would seriously consider sending ALUA commands to the multipath
> devices. TUR and REQUEST SENSE are other examples for commands that
> can't be reasonably passed through to random member devices of a
> multipath map.

Yes, as usual things are a bit more complicated. First, a handful of
commands are special (REQUEST SENSE would be for HBAs that don't use
auto sense, but that is fortunately not something you encounter).
Second, there's already a filter in the kernel in
drivers/scsi/scsi_ioctl.c for commands that are allowed without
CAP_SYS_RAWIO. QEMU is subject to that so the commands you'll see are
mostly I/O, INQUIRY, TUR, MODE SENSE/SELECT and that's it.

Any command that the kernel doesn't filter would be rejected, or
handled specially in the case of PR commands (PR commands use a
separate privileged helper to send them down to the device; the helper
also knows about multipath and uses the userspace libmpathpersist if
it receives a dm-mpath file descriptor via SCM_RIGHTS).

> AFAIK the only commands that we really need to pass through (except the standard ones) are the reservation commands, which get special handling
> by qemu anyway. @Ben, @Kevin, are you aware of anything else?

.Of the ones that aren't simple I/O, mode parameters and TUR are the
important cases. A TUR failure would be handled by the ioctl that
Kevin proposed here by forcing a path switch. Mode parameters might
not be shared(*) and would need to be sent down all the paths in that
case; that can be fixed in userspace if necessary.

> I'd also be interested in understanding this better. As noted above,
> I'm aware that passing through everything is dangerous and wrong in
> principle. But in practice, we haven't observed anything serious except
> (as Ben already said) the failure to do path failover in the SG_IO code
> path, which both this patch set and my set from the past are intended
> to fix.

Yes, the kernel filter is a PITA in the normal single path case but
here it helps not doing something overly wrong.

Paolo

(*) in theory there's a Mode Page Policy VPD page to tell the
initiator whether they are. I'm not sure if anyone supports it in the
real world...

Powered by blists - more mailing lists