Re: [PATCH RFC 0/2] Fix API breakage in libblkid

[Zdenek Kabelac <zkabelac@redhat.com>]

Dne 08. 04. 26 v 15:19 Carlos Maiolino napsal(a):
> On Wed, Apr 08, 2026 at 01:47:27PM +0200, Zdenek Kabelac wrote:
>> Dne 08. 04. 26 v 12:35 cem@kernel.org napsal(a):
>>> From: Carlos Maiolino <cem@kernel.org>
>>>
> So, although I agree with you that Stratis is using libblkid incorrectly,
> I still think this patch is wrong, as it changes the library's behavior
> to fix a problem in LVM (if there is where the race was), and not some
> inherent library problem. If, no user can use libblkid to query into a
> private device, then the above lib call sequence wasn't supposed to work
> either, and perhaps then, blkid_probe_set_device() should actually fail
> in a private device.
> 
> Again, I just looked into the libblkid low-level implementation today,
> but it doesn't seem to be the library's job to be responsible for a race
> between open() and ioctl(DM_DEVICE_REMOVE).
> 

Hi

The main missed concept here is  -  this is not breaking any API.

The concept of private DM device is to be a device that is not being touched 
by libblkid.  So this was a pure bug in the libblkid code when there was a 
code path skipping check (and actually doing this check after opening private 
device).

And actually IMHO there is a bigger issue -  xfs tools are actually relying 
too much on content of udev DB - this DB is by design unreliable - so it's 
likely good for some quick checking - but i.e. in lvm2 - we always do a real 
disk read -  udevDB is only advisory.


Regards

Zdenek