Re: [PATCH] generic/492: bypass the blkid cache when probing the label

[Baokun Li <libaokun@linux.alibaba.com>]

On 2026/9/22 23:56, Theodore Tso wrote:
> On Tue, Sep 22, 2026 at 03:17:27PM -0500, Baokun Li wrote:
>> I checked my environment again though -- it turned out not to be
>> xfstests-bld at all.  xfstests-bld never touches e2fsprogs.
>>
>> What happened is that I had manually run "make install" of a locally
>> patched e2fsprogs in the test VM, which overwrote util-linux's blkid
>> and fsck.
> What e2fsprogs's configure script will do is that it checks to see if
> the blkid libraries are available for building against.  That is, if
> you are using Debian or Ubuntu, you need to have the libblkid-dev
> package install.  Among other things, this makes the following files
> available:
>
> /usr/include/blkid/blkid.h
> /usr/lib/x86_64-linux-gnu/libblkid.a
> /usr/lib/x86_64-linux-gnu/libblkid.so
>
> ... which are the files needed to build against libblkid and then link
> against it statically or dynamically.  If these files aren't
> available, then e2fsprogs will assume that it needs to build the local
> libblkid, which is what is needed when building on Android, MacOS,
> NetBSD, Open Solaris, etc.

Indeed, I originally built and installed it manually in an
environment without libblkid-dev.

>> Rebuilding e2fsprogs with these options disabled made the test pass:
>>
>>     ./configure --disable-libblkid --disable-fsck \
>>             --disable-libuuid --disable-uuidd
> This works, but this wll also disable those e2fsprogs features that
> require those libraries.  So mke2fs will not generate UUID's in the
> superblock, e2fsck won't handle LABEL=xyzzy specifiers, etc.
> Fortunately xfstests don't depend on these featuers, so this will work.


Hmm, what I disabled is exactly the set duplicated by util-linux:
the blkid/uuid libs and UUID/LABEL= handling all live there, so
the tools just link the system ones -- there is no functional loss.

> The way I build with a locally patched e2fsprogs is that I'll build it
> using the Debian build tools, which will enforce building with the
> necessary prereqsuite packages, and then I'll put the built packages
> in the directory test-appliance/debs and then build a fresh test
> appliance image.  Or I'll just upload the packages to the VM and then
> install it before launching the tests.

That sounds much better than a hand install -- I'll give it a try.

>> That said, I think the patch is still needed, because
>> FS_IOC_SETFSLABEL does not update the block device's mtime:
>>
>>     blkid -s LABEL ...    # get A
>>     FS_IOC_SETFSLABEL     # set B (device mtime unchanged)
>>     blkid -s LABEL ...    # still get A (within 2s)
>>
>> The first read writes a cache entry with TIME=now, and the ioctl
>> leaves the device mtime untouched, so a second read within the 2s
>> window still trusts the cache.
> The patch to xfstests might still be appropriate, but it seems to me
> that tune2fs should get fixed to update the device mtime (if it can),
> and perhaps the kernel should try to update block device inode as well
> as part of the FS_IOC_SETFSLABEL ioctl to address potential corner
> cases with systemd/udev.


Yes -- we need to add a utime() in tune2fs's ioctl path to update
the device mtime; I'll send a patch shortly.

For the kernel side, we don't have the dev path that the caller
is using, so it is not doable there: the inode we can reach
inside the ioctl is not the one userspace sees.  Details are in my
reply to Darrick:

https://lore.kernel.org/all/eeeab8d8-dfd3-45ff-9f30-d83c527210f2@linux.alibaba.com

Also, a thought that just came up: on the blkid side, would it be
feasible to not trust the cache for mounted devices and always
re-probe?  The mount / set label / umount / get label (within 2s)
window would remain, but it would be much smaller.


Thanks,
Baokun