From: "Darrick J. Wong" <djwong@kernel.org>
To: Baokun Li <libaokun@linux.alibaba.com>
Cc: fstests@vger.kernel.org, zlang@kernel.org,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
sandeen@redhat.com, dgc@kernel.org
Subject: Re: [PATCH] generic/492: bypass the blkid cache when probing the label
Date: Mon, 21 Sep 2026 16:49:10 -0700 [thread overview]
Message-ID: <20260921234910.GC6253@frogsfrogsfrogs> (raw)
In-Reply-To: <b4a10712-1658-4fba-a037-095fab466270@linux.alibaba.com>
On Mon, Sep 21, 2026 at 05:07:48PM +0800, Baokun Li wrote:
> Hi Darrick,
>
> On 2026/9/21 13:27, Darrick J. Wong wrote:
> > On Sun, Sep 20, 2026 at 05:41:37PM +0800, Baokun Li wrote:
> >> blkid may serve a stale label from its cache instead of probing the
> >> device, so the label just set via xfs_io can be missed and the output
> >> mismatch is non-deterministic.
> >>
> >> Pass "-c /dev/null" so that blkid always probes the on-disk superblock
> >> directly. Unlike the low-level probing mode (-p), which requires
> >> util-linux 2.16 or later, this is also supported by the legacy blkid
> >> shipped with e2fsprogs.
> >>
> >> Fixes: c3c9630968a6 ("generic: test online label ioctl")
> >> Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
> > Seems fine to me; I guess blkid could be racing with whatever updates
> > the cache...udev?
>
>
> Not a race, and not related to udev. It's a long story; details below.
>
> In the xfstests-bld appliance blkid is e2fsprogs' legacy blkid and its
> cache is /etc/blkid.tab; the only writers are blkid itself and
> e2fsprogs' fsck (both probe with the cache enabled). systemd's udev
> uses libblkid's low-level probe API and never touches this file.
>
> What we hit is a strictly sequential sequence that depends on two
> "same second" coincidences. The cache validity check (blkid_verify()
> in lib/blkid/probe.c) is:
>
> now >= TIME && mtime(seconds) <= TIME && age < 2s
>
> Both sides are in seconds, and only the 2s window applies to a fresh
> blkid process (BLKID_BID_FL_VERIFIED is not persistent).
>
> mkfs only advances the device mtime and never updates the cache; the fs
> label ioctl updates neither, so right after setting a new label a
> cached lookup can still return the old one.
>
> The trap is set by _check_scratch_fs: it runs "fsck -t ext4 ...", which
> probes the device with the cache enabled and writes the entry back with
> TIME=now and the current label state.
>
> Here is a sequential 490/491/492 run that trips it (timestamps from a
> CI log, ext4/bigalloc_1k):
>
> M-2 09:09:44 end of 490: fsck finds the previous entry stale
> (age >= 2s) -> probes -> tab = {no LABEL, TIME=44}
>
> M-1 09:09:45 start of 491: mkfs -> device mtime = 45
> (mkfs doesn't update the cache; tab stays TIME=44)
> M 09:09:46 end of 491: unmount + _check_scratch_fs
> -> fsck sees mtime(45) > TIME(44) -> probes
> -> tab = {no LABEL, TIME=46} <- trap
>
> M 09:09:46 start of 492: mkfs -> device mtime = 46
> M 09:09:46 mount; ioctl label="label.492" (mtime unchanged)
> M 09:09:46 blkid(35): mtime(46) <= TIME(46), age < 2s
> -> cache deemed valid, no probe -> prints no LABEL
> M+1 09:09:47 umount; blkid(39): still < 2s -> again
> M+1 09:09:47 check reports output mismatch (two lines missing)
>
> 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.
[add ext4 list to cc]
Perhaps xfstests-bld should use the system blkid then? IIRC the one
in e2fsprogs is very old and out of date.
--D
>
> The patch avoids this by probing with -c /dev/null (the legacy blkid
> has no -p). Reproduced on ext4/bigalloc_1k: unpatched 10 of 65 runs
> fail, patched 120/120 pass.
>
>
> >
> > Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>
> >
> > --D
>
>
> Thanks for the review!
>
> Cheers,
> Baokun
>
>
next prev parent reply other threads:[~2026-09-21 23:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-20 9:41 [PATCH] generic/492: bypass the blkid cache when probing the label Baokun Li
2026-09-21 5:27 ` Darrick J. Wong
2026-09-21 9:07 ` Baokun Li
2026-09-21 23:49 ` Darrick J. Wong [this message]
2026-09-22 3:43 ` Theodore Tso
2026-09-22 7:17 ` Baokun Li
2026-09-22 14:53 ` Darrick J. Wong
2026-09-23 9:13 ` Baokun Li
2026-09-22 15:56 ` Theodore Tso
2026-09-23 10:02 ` Baokun Li
2026-09-24 2:25 ` Theodore Tso
2026-09-24 8:09 ` Baokun Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260921234910.GC6253@frogsfrogsfrogs \
--to=djwong@kernel.org \
--cc=dgc@kernel.org \
--cc=fstests@vger.kernel.org \
--cc=libaokun@linux.alibaba.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=zlang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.