On Tue, 2026-02-10 at 08:59 -0500, Stefan Hajnoczi wrote: > 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.
Right. We shouldn't do that. If we find we have to, we _must_ remove the "watch" udev property from the devices in question. Martin
