Re: Moving from qemu-pr-helper and libmpathpersist to <linux/pr.h>

[Stefan Hajnoczi <stefanha@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Tue, Feb 10, 2026 at 11:23:51AM +0100, Martin Wilck wrote:
> On Mon, 2026-02-09 at 09:23 -0500, Stefan Hajnoczi wrote:
> > On Mon, Feb 09, 2026 at 01:50:00PM +0100, Hannes Reinecke wrote:
> > > 
> > > My concern with opening the block device with BLK_OPEN_WRITE is
> > > that
> > > this will trigger udev to 'synthesize' (ie regenerate) an 'add'
> > > event
> > > on close, causing 'interesting' effects as this will cascade down
> > > through the udev rule chain, triggering blkid, partition scan, you
> > > name it.
> > > Horrible, horrible, horrible.
> > > Don't do it.
> > > 
> > > Especially not as you are only interested in reading information,
> > > and not changing the disk state in any way.
> > 
> > I see. I will send patches to change blkdev_pr_read_keys()
> > blkdev_pr_read_reservation() to require only BLK_OPEN_READ.
> 
> Hm, but then if you need to make an actual reservation and call e.g.
> blkdev_pr_reserve(), you'll need to re-open the device r/w, and have
> the same problem. I'm not sure I understand the issue here ... doesn't
> your process have an open fd to the device in question anyway? You just
> need to be sure not to _close_ it, as that's what causes the uevents
> (udev uses an IN_CLOSE_WRITE inotify(7) event on the device node).

Shell scripts are the most exposed to this issue because they invoke
blkpr(8) anew each time instead of keeping the fd open between reading
reservation details and performing a reservation operation.

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]