On 2/4/26 19:32, Stefan Hajnoczi wrote:
On Wed, Feb 04, 2026 at 02:19:48PM +0100, Martin Wilck wrote:
Hi Stefan,
On Tue, 2026-02-03 at 13:04 -0500, Stefan Hajnoczi wrote:
[ .. ]>>>
It can be generic. The messages will contain the block device
major:minor as well as information to describe <linux/pr.h> requests.
So the ioctls will pass through qemu into the kernel, to be intercepted
by the dm-mpath driver, which will use an upcall to have them handled
by mpathpersistd (for the actual command) and multipathd (for the path
registrations).
I don't fully understand the advantage, security and complexity-wise,
of this concept, compared to intercepting them qemu and using a socket
to talk to mpathpersistd directly. If we did this, we could even
support both generic and SCSI PR commands.
Hi Martin,
The simplification and security benefits are on the application side,
not on the DM-Multipath side, so I can see what you're getting at. From
the DM-Multipath perspective things get a little more complex.
From an application perspective, a single API that works across block
device types (SCSI, NVMe, DM-Multipath) and requires no privileges or
sockets (they are a pain in container environments) is the most
convenient. The <linux/pr.h> ioctl API offers exactly this.
Unfortunately, DM-Multipath currently does not fully support
<linux/pr.h>. It sends PR operations down each path, but that is only a
subset of libmpathpersist's logic and multipathd is not kept in sync.
My impression is that libmpathpersist and multipathd logic cannot be
easily moved into the kernel. This is where the upcall idea comes from.
Let's notify multipath-tools from DM-Multipath so it can do its work in
userspace.
It _might_ be possible by extending the current path-switching
code in the kernel to keep track of PRs. The we could move the
registration upon path switching, and (ideally) could do away
with upcalls.
Not sure, though, how targets react when having to deal with a
flood of PR commands ...
But maybe worth a try.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
[email protected] +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
