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

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

On 2026/9/22 22:53, Darrick J. Wong wrote:
> On Tue, Sep 22, 2026 at 03:17:27PM +0800, Baokun Li wrote:
>> On 2026/9/22 11:43, Theodore Tso wrote:
>>> On Mon, Sep 21, 2026 at 04:49:10PM -0500, Darrick J. Wong wrote:
>>>>> The difference between the e2fsprogs and util-linux libblkid is the
>>>>> time granularity: the former stores seconds only (TIME="%ld",
>>>>> bid_time = time(0), compares st_mtime <= bid_time), while the latter
>>>>> stores usec (TIME="sec.usec") and has an nsec tie-break in the compare,
>>>>> so the same-second case is much easier to hit with the e2fsprogs blkid.
>>>> Perhaps xfstests-bld should use the system blkid then?  IIRC the one
>>>> in e2fsprogs is very old and out of date.
>>> Historically, xfstests-bld was built in environments where libblkid
>>> wasn't available.  This included Android's runtime (which uses the
>>> bionic libc), and grte (Google Runtime Environment)[1].
>>>
>>> [1] https://github.com/bazelment/lrte/blob/master/grte/grte-build
>>>
>>> However, as more and more tests require utilities from util-linux,
>>> xfstests-bld was taught to build util-linux.  And if util-linux is
>>> being built, then we don't use e2fsprogs-libs any more, which is where
>>> libblkid is built.  From build-all:
>>>
>>> if test -z "$USE_LOCAL_E2FSLIBS" -o -d util-linux; then
>>>     SKIP_E2FSLIBS=yes
>>> fi
>>>
>>> I've always built xfstesets-bld with util-linux, even though it is
>>> listed as an optional repository.  This is because (a) util-linux is
>>> needed for Android and other non-standard Linux environments, and (b)
>>> the version of util-linux used by earlier Debian Stable was too old
>>> for some of the newer tests in fstests and blktests.
>>>
>>> If you aren't building xfstests-bld with util-linux, it falls back to
>>> building libblkid from e2fsprogs-libs.  HOWEVER, we don't actually
>>> blkid, and libblkid is always built statically.  So what seems to be
>>> going on is that one of the programs built by xfstests-bld is using
>>> the older libblkid, and that results in the blkid cache being writen
>>> with a second granularity.
>>>
>>> I've never noticed this issue because I've always built with
>>> util-linux.  The way to solve this is to require building with the
>>> system libblkid if util-linux is not being built, and to drop
>>> e2fsprogs-libs from xfstests-bld.  Or just build xfstests-bld with
>>> util-linux.  :-)
>>
>> Thanks for the detailed explanation.
>>
>> 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.
>>
>> Rebuilding e2fsprogs with these options disabled made the test pass:
>>
>>     ./configure --disable-libblkid --disable-fsck \
>>             --disable-libuuid --disable-uuidd
>>
>> I ran unpatched generic/492 60 times on each side in a VM: 12/60
>> failures with the hand-installed strays, 0/60 with util-linux's
>> blkid/fsck.
>>
>> That said, I think the patch is still needed, because
>> FS_IOC_SETFSLABEL does not update the block device's mtime:
> Many filesystems /never/ update the bdev mtime, why would they?


Not from FS_IOC_SETFSLABEL, at least -- as far as I can see, none of
the filesystems implementing it updates the mtime, and even btrfs does
not do it from its label ioctl.  btrfs does have update_dev_time() for
the add/remove case (5a1972bd9fd4, so that libblkid does not keep
reading a stale cache), but that is not wired into its label ioctl.

I can see why.  What blkid keys on is the mtime of the /dev/xxx node,
and once the mount is set up we hold no reference to that path anymore
-- the node can be deleted or re-created, and s_id only keeps an
informational name.

Worse, one block device can have any number of /dev nodes pointing at
it; an ioctl on a mountpoint fd cannot tell which one the caller means,
nor find them all.  So the kernel has no well-defined node to update
here.

And it gets easy in userspace: for tools that take the device as an
argument (tune2fs, e2label, xfs_admin), one utime(device_name, NULL)
is enough to guarantee that after set the label of a device with
the tool, blkid -s <device> won't see the old label.

The tricky counterpart is the standard way to invoke this ioctl: a
mountpoint as the argument, xfs_io being the typical case.  It seems
the only option there is what the kernel would have to do anyway --
resolve the device behind the mount and update that node's mtime.

Do you have any thoughts?


>>     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.
>>
>> I reproduced this with util-linux 2.41.5 too, so
>> "blkid -c /dev/null" is what keeps the test deterministic
>> regardless of which blkid the image carries.
> <nod> That was the problem I thought you were solving here ;)

Yep, that's the idea.  The point was to stay away from blkid's
cache complexity -- testing how a userspace tool caches things is
not really what a kernel test should be doing.


Cheers,
Baokun