This conversation was generated with Duck.ai (https://duck.ai)
using OpenAI's GPT-6 Luna Model.  AI chats may display inaccurate or
offensive information (see https://duckduckgo.com/duckai/privacy-terms
for more info).

====================

User prompt 1 of 2 - 10/10/2026, 2:57:47 PM:
Hello, Duck.

I read this on alt.os.linux.slackware (Usenet), but either the concepts
or the grammar, or both, conspire to prevent understanding.  Can you
explain, please?:


Interesting mailing list message from Ted Tso:

"Cqn [sic] you name any other OS that has implemented

	https://systemd.io/BLOCK_DEVICE_LOCKING/

*other* than systemd?  So for non-systemd distros, who cares if we don't
have the functionality?  So what we could do is to use autoconf with
something like this:

AC_CHECK_LIB(libsystemd, sd_device_get_parent_with_subsystem_devtype,
	AC_DEFINE(HAVE_SD_DEVICE_GET_PARENT_WITH_SUBSYSTEM_DEVTYPE, 1,
		[Define to 1 if libsystemd has
		sd_device_get_parent_with_subsystem_devtype]))
"

https://lore.kernel.org/linux-ext4/20260824224006.GB6038@frogsfrogsfrogs/t/#m4743eec8fcce7a519b0b0e69ca5a6ce5c4b45e6a

So yay that e2fsprogs will still build on slackware if they end up being
the project that takes responsibility for acquiring the missing lock. But
boo-hoo that there's no awareness that this hypothetically affects us too.
Or maybe I don't know what I'm talking about.

In short...

1. we get symlinks in /dev/disk/by-uuid because of these udev
   rules in 60-persistent-storage.rules:

   # probe filesystem metadata of disks KERNEL!="sr*",
   IMPORT{builtin}="blkid"

   # by-label/by-uuid links (filesystem metadata)
   ENV{ID_FS_USAGE}=="filesystem|other|crypto", ENV{ID_FS_UUID_ENC}=="?*",
   SYMLINK+="disk/by-uuid/$env{ID_FS_UUID_ENC}"
   ENV{ID_FS_USAGE}=="filesystem|other", ENV{ID_FS_LABEL_ENC}=="?*",
   SYMLINK+="disk/by-label/$env{ID_FS_LABEL_ENC}"

2. ENV{ID_FS_UUID_ENC} only can exist if the earlier import from the
   builtin libblkid code succeeds in reading the filesystem uuid out of
   the superblock

3. If e2fsck is in there writing (and, I believe, even if it just
   updates a couple fields in the superblock after finding the fs to be
   clean) while eudev's liblkid calls are also in there reading, well,
   trouble. Unless there's locking between e2fsck and udevd (and a lock
   that's actually on the same device, the disk device, which is not
   currently the case)

4. eudev does its part and takes a read (shared) lock in
   worker_lock_block_device() in udevd.c:
    if (flock(fd, LOCK_SH|LOCK_NB) < 0)
         return log_device_debug_errno(dev, errno, "Failed to flock(%s):
         %m", val);

5. The subject of the e2fsck thread linked above is about how there's
   been no other end of that lock for more than a decade now, since
   util-linux fsck stopped taking its lock on the whole disk in favour of
   a private lock file under /run.

I'm not at all convinced this only effects systemd systems. What protects
us other than fortunate timing for uevents vs. when rc.S runs fsck?

- Mike Sm.


GPT-6 Luna:


The post is about a **race condition**: two programs may access the
same disk metadata at the same time.

- **udev** reacts to device events and runs `blkid` to identify
  filesystems.  If it reads a filesystem’s UUID, a rule can create a
  convenient symlink such as `/dev/disk/by-uuid/...`.

- **e2fsck** may write filesystem metadata while checking or repairing
  a filesystem.  If `blkid` reads during that write, it might
  temporarily fail to recognize the UUID.  udev can then remove the
  symlink; it may reappear when a later probe succeeds.  A recent
  report describes this sort of race during ext4 journal recovery.  [1]

The proposed coordination mechanism is `flock()` on the **block-device
node**.  udev takes a nonblocking shared lock while probing.  A program
that is about to change filesystem metadata is supposed to take an
exclusive lock on the same device: that makes it wait for an ongoing
probe and prevents a new one from overlapping its work.  The locks are
advisory, though: they help only if both programs use the same locking
convention on the same device.  [2]

The claimed gap is that modern `fsck` locking may protect only against
*other fsck runs*, using a private lock file under `/run`; that does
not coordinate with udev’s lock on the device.  So if e2fsck writes
while udev probes, the shared/exclusive device-lock handshake may be
missing.  The message’s point is that this could matter outside systemd
too: eudev also has code that takes a shared device lock, so the reader
side of the scheme is not necessarily systemd-only.  The concern is
whether Slackware’s fsck/e2fsck path takes the matching exclusive lock. 
[1]

Ted Tso’s suggestion is essentially: “If systemd is the only project
using this particular systemd-provided helper, make e2fsprogs’ use of
it optional at build time.” The `AC_CHECK_LIB` snippet asks whether
`libsystemd` provides a function that can find a partition’s parent
device; e2fsprogs could then use the systemd helper where available and
still build without it elsewhere.  That addresses portability of the
*implementation*, but it doesn’t settle who should provide locking on
non-systemd systems.

So Mike’s final question is reasonable: **what, if anything, protects
Slackware from the race?** Based on the post alone, the answer is not
“the `/dev/disk/by-uuid` rules.” Those rules create the links, but they
don’t themselves prevent concurrent reads and writes.  Protection
requires a matching exclusive lock from the filesystem-checking side—or
some other coordination mechanism.  The timing of boot events might
often avoid trouble, but it is not a synchronization guarantee.  [1,2]

Read More

[1] systemd-fsck can race with udev probing during journal ...  —
https://github.com/systemd/systemd/issues/43695

[2] Locking Block Device Access — https://systemd.io/BLOCK_DEVICE_LOCKING/

--------------------

User prompt 2 of 2 - 10/10/2026, 3:10:19 PM:
Thanks, Duck.  That helps me to understand.

By the way, the poster replied to his own post.  Does his reply color
your response?:

Mike Small  writes:
>
> 4. eudev does its part and takes a read (shared) lock in
>    worker_lock_block_device() in udevd.c:
>     if (flock(fd, LOCK_SH|LOCK_NB) < 0)
>          return log_device_debug_errno(dev, errno, "Failed to flock(%s):
>          %m", val);

I looked at the wrong udev. In eudev it looks like this...

if (d) {
        fd_lock = open(udev_device_get_devnode(d),
        O_RDONLY|O_CLOEXEC|O_NOFOLLOW|O_NONBLOCK);
        if (fd_lock >= 0 && flock(fd_lock, LOCK_SH|LOCK_NB) < 0) {
                log_debug_errno(errno, "Unable to flock(%s), skipping
                event handling: %m", udev_device_get_devnode(d));
                fd_lock = safe_close(fd_lock);
                r = -EAGAIN;
                goto skip;
        }
}

So maybe Ted Tso is correct (as usual?). If we can't get the lock we skip
udev rule processing and don't read the uuid anyway. The copy of systemd
udevd source I have locally (inappropriately sitting on a Slackware fs,
which must feel an itch) shows them reacting to not getting the read lock
by starting up an inotify job to try to get back that uevent again later.

So same as having the bug only more tidy, in a way? Seems like eudev would
need a fix for the possible future e2fsprogs locking to even help us.

- Mike Sm.


GPT-6 Luna:



Yes—it changes one important part of the explanation.  My previous
answer made eudev sound as if it simply probed under a shared lock and
then carried on.  Mike’s correction says that, in the eudev code he
found, failure to get that lock makes it **skip handling the event**. 
So eudev won’t read the UUID during the lock conflict.

That means a matching exclusive lock in e2fsprogs could prevent the
*simultaneous access* problem for eudev too.  But avoiding the
collision is only half the story: after e2fsck releases the lock, eudev
still needs another chance to process the device and probe its UUID. 
systemd’s described design watches for a device-node close and uses
that as a cue to retry the event; Mike says the eudev code he inspected
didn’t appear to do that.  [1]

So Mike’s revised conclusion is sensible: **eudev’s shared lock alone
doesn’t complete the handshake.** If e2fsprogs starts taking an
exclusive lock, eudev may skip a conflicting event, but it also needs a
reliable way to retry afterward.  Without that, the race might be
avoided while the lock is held, yet the UUID symlink could still fail
to appear until some later event causes another probe.

That doesn’t necessarily mean Ted is wrong.  Ted’s suggestion is about
making e2fsprogs’ use of a systemd-specific helper optional so it can
build on other systems.  Mike’s follow-up points out that, for eudev,
the bigger question is whether it will properly resume processing after
a lock conflict.  In other words, there are two separate issues: **who
takes the matching lock, and who retries the skipped udev work
afterward.** [1]

Read More

[1] Locking Block Device Access —
https://systemd.io/BLOCK_DEVICE_LOCKING/