From Newsgroup: alt.os.linux.slackware


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.



--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: alt.os.linux.slackware

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.




--- Synchronet 3.22a-Linux NewsLink 1.2