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

Dne 08. 04. 26 v 16:49 Carlos Maiolino napsal(a):
> 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.
> 


Well - DM with private suffix is private  - that's the API  and defined long 
time in history - to avoid any interaction with private device and libblkid.

The fact here was a bug for a long while that such device could have been 
still explored by some libblkid calls does not make it a legit API.

Stratis has 2 easy solutions/fixes:

a) dropping  'private' check for their device in util-linux.

b) use non-private UUID for a device that should be managed by user-space tools.

For lvm2/dm - it's clear we never want libblkid to access internal raid legs 
or other types of private DM devs.

Also it should be noted - Stratis should not have been using 'internal' logic 
without fully understanding concept of 'private' device in the 1st. place....

So eventually as a 'middle' ground solution we may possibly have new:

    sysfs_devno_is_dm_really_private()

that would be called in my patch in this function that would be a replica of 
sysfs_devno_is_dm_private() just with LVM suffix check.
But still this kind of defeats the original 'intention' of this check and 
makes the code harder to follow.

So I'd still prefer a fix on Stratis to correct notation of the private device.

Regads

Zdenek