On Wed, 2026-02-04 at 13:32 -0500, Stefan Hajnoczi wrote: > On Wed, Feb 04, 2026 at 02:19:48PM +0100, Martin Wilck wrote: > > Hi Stefan, > > > > 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.
I may be missing something, but AFAICS the PR ioctls require having a block device open for writing, which does either require root privileges, or some file descriptor previously opened with privileges and forwarded to another, less privileged process. No? > 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. I agree. > Getting back to the application vs DM-Multipath advantages: I think > it's > worth simplifying things for applications because there are many > applications and only one DM-Multipath. TBH, I don't see so many applications. Actually I am having trouble finding any application at all that uses the generic linux PR functionality. I haven't even found a basic command line tool that encapsulates the ioctls, are you aware of one? That would be the first thing we need, be it only for testing the kernel. As for applications using SCSI/NVMe PRs, I also don't see many, at least not in the Linux / open source realm. Actually, qemu is the only one that immediately comes to my mind. I can imagine that storage management tools for e.g. OpenStack or Kubernetes would want to use PRs, but I don't know any details. Wrt sockets, not sure what's so painful about them. multipathd recently enabled a pathname sockets for qemu-pr-helper in KubeVirt [1]. Thanks, Martin [1] https://github.com/opensvc/multipath-tools/issues/111
