linux-kernel - Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active paths

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCbSj9HLGJD1dK3u@infradead.org>
Date: Thu, 15 May 2025 22:52:15 -0700
From: Christoph Hellwig <hch@...radead.org>
To: Benjamin Marzinski <bmarzins@...hat.com>
Cc: Christoph Hellwig <hch@...radead.org>, Hannes Reinecke <hare@...e.de>,
	Kevin Wolf <kwolf@...hat.com>, Martin Wilck <mwilck@...e.com>,
	dm-devel@...ts.linux.dev, hreitz@...hat.com, mpatocka@...hat.com,
	snitzer@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] dm mpath: Interface for explicit probing of active
 paths

On Tue, May 13, 2025 at 12:29:51PM -0400, Benjamin Marzinski wrote:
> On Mon, May 12, 2025 at 11:49:19PM -0700, Christoph Hellwig wrote:
> > On Tue, May 13, 2025 at 08:32:12AM +0200, Hannes Reinecke wrote:
> > > Reservations and stuff.
> > 
> > They should use the kernel persistent reservation API.
> 
> Currently QEMU isn't sending Persistent Reservation requests to
> multipath devices at all. It's sending those directly to the underlying
> scsi devices. The issue here is with all the other SCSI commands that
> users want to send to their SCSI passthrough device that is actually a
> multipath device on top of a number of SCSI paths. They expect to
> get back the actual sense and status information, so QEMU needs to
> send them via SG_IOs.

And that's the problem.  There is plenty of path (I_T_L) nexus
specific information in SCSI, and just trying to glob it back
together above means you'll get path specific information in something
that doesn't claim to be multi-pathing and will get random and
changing results depending on the underlying path selection.

> Without reading that sense and status information in kernel, the
> multipath target can't know if it needs to fail a path and retry the
> ioctl down a different path.

The blk_status_t has the information to fail over.  But the whole
idea of implementing SG_IO in dm-mpath or any other stacking layer
is just really, really dangerous.