Il mer 14 mag 2025, 13:37 Martin Wilck <mwi...@suse.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...
