Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux.slackware > #35823 > unrolled thread

e2fsprogs - maybe we don't get the fix

Back to article view | Back to alt.os.linux.slackware

Contents

  e2fsprogs - maybe we don't get the fix Mike Small <smallm@panix.com> - 2026-09-29 19:32 -0400
    Re: e2fsprogs - maybe we don't get the fix Mike Small <smallm@panix.com> - 2026-09-29 20:25 -0400

#35823 — e2fsprogs - maybe we don't get the fix

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.

[toc] | [next] | [standalone]

#35824

Mike Small <smallm@panix.com> 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.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux.slackware

csiph-web