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

On Wed, Apr 08, 2026 at 03:32:14PM +0200, Zdenek Kabelac wrote:
> 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 [email protected] napsal(a):
> > > > From: Carlos Maiolino <[email protected]>
> > > > 
> > 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.

I disagree... Same lib call, same device, works before your patch, does
not after... You may call it a bug that shouldn't be relied on, but
that's for sure an API breakage.

> 
> 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).

Ok, you told me from where it comes from.

How different is it of any other tool that uses libblkid doing
open(); blkid_new_probe(); blkid_probe_set_device();

Instead of calling blkid_new_probe_from_filename() directly?

Because this still can easily access a 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.

We don't do anything with udev. We use libblkid to query device's
geometry to properly configure the filesystem to be initialized there.
If blkid_new_probe_from_filename() fails, mkfs abort. It's up to the
user to pass the right device.

> 
> 
> Regards
> 
> Zdenek
>