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

Groups > alt.os.linux.slackware > #35824

Re: e2fsprogs - maybe we don't get the fix

Show all headers | View raw

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.

Back to alt.os.linux.slackware | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

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

csiph-web