Re: [PATCH v3] e2fsck: take flock(LOCK_EX) on whole-disk device during filesystem check

["Darrick J. Wong" <djwong@kernel.org>]

On Mon, Oct 05, 2026 at 03:35:11PM +0000, Mike Small wrote:
> "Darrick J. Wong" <djwong@kernel.org> writes:
> 
> > On Wed, Sep 23, 2026 at 03:55:23PM -0400, Dan Streetman wrote:
> >> 
> >> 
> >> On Sun, 20 Sep 2026, Nandakumar Raghavan wrote:
> >> 
> >> > On Thu, Sep 10, 2026 at 05:04:41AM -0700, Nandakumar Raghavan wrote:
> >> > > During journal replay, e2fsck writes the primary superblock back to disk
> >> > > in multiple I/O operations. The payload lands before the checksum, leaving
> >> > > a transient window where the on-disk superblock has a bad checksum.
> >> > > 
> >> > > If udevd processes a change uevent during this window, libblkid probes the
> >> > > primary superblock, finds a checksum mismatch, and concludes the partition
> >> > > has no recognisable filesystem. udev then fires a remove event, wiping all
> >> > > symlinks in /dev/disk/by-label/ and /dev/disk/by-uuid/. Any mount unit
> >> > > that depends on those symlinks will fail.
> >> > > 
> >> > > udevd already serialises its own partition probes against whole-disk device
> >> > > access using flock(LOCK_SH|LOCK_NB); if EAGAIN is returned it requeues the
> >> > > event. Take advantage of this protocol by acquiring flock(LOCK_EX) on the
> >> > > whole-disk device before opening the filesystem. This forces udevd to defer
> >> > > all probes on that disk until e2fsck exits and the lock is released, by
> >> > > which point the filesystem is fully consistent.
> ...
> >> > Gentle ping on this patch.
> >> > 
> >> > I would appreciate any feedback.
> >> > 
> >> 
> >> Can you clarify why this should go into only fsck.ext4? Doesn't this
> >> problem exist for other filesystems too?
> >> 
> >> I sent an earlier email as well with links to:
> >> 
> >> 1) fsck used to lock the device, but it surfaced a bug in udevd
> >> https://bugs.freedesktop.org/show_bug.cgi?id=79576
> >> 
> >> 2) because of the bug, fsck stopped locking the device
> >> https://github.com/util-linux/util-linux/commit/3bbdae633f4a1dda5f95ee6c61f18a1c8ef12250
> >> 
> >> 3) the systemd-udevd bug was fixed
> >> https://github.com/systemd/systemd/commit/5d354e525a5
> >> 
> >> To me, it makes more sense for the locking that already exists in fsck
> >> to get updated (or reverted) to lock the entire device, using the
> >> existing -l param (or maybe a new param like --lock-device,
> >> --udevd-lock, etc., if util-linux maintainers don't want to change -l
> >> behavior).
> >> 
> >> Do you see an issue with doing the locking there instead of here in
> >> fsck.ext4?
> >
> > /sbin/fsck (aka the dispatch wrapper program) doesn't necessarily know
> > which block device(s) are going to be opened by a the fsck.$FSTYP
> > program that it creates.  It might be able to infer that by opening any
> > parameter and performing the udev locking protocol after checking if
> > what it opened is a block device, but that wouldn't work for (say) a
> > fsck.XXX program for a multi-device filesystem wherein you only need to
> > specify one device and it will find the others.
> >
> > That said, this patchset also doesn't handle multi-device ext4
> > filesystems (i.e. external jbd2 journal device) because the author
> > doesn't want to do that.  In their defense, the udev flock()ing protocol
> > requires one to determine if an opened block device is a partition; if
> > it is, then it requires opening and locking the parent bdev (e.g. sdf1
> > -> sdf) instead of locking the original device.  This makes it way more
> > complicated for multi-device filesystems because now the client has to
> > detect multiple partitions coming from the same underlying device and
> > handle that appropriately.  I don't know why the protocol designers made
> > that choice.
> >
> > I can run "trace-cmd record -e 'flock*'" to observe the locking
> > interactions with scsi disk partitions, but for whatever reason I don't
> > see any flocking going on if I use kpartx to create the partitions with
> > device-mapper.  No idea why that is.
> >
> > --D
> 
> Systemd-udevd will not take its shared lock when the device in the
> uevent starts with "dm-", "md", or "drbd". See udev_get_whole_disk() in
> src/udev/udev-worker.c and how that's used by worker_lock_whole_disk().

Doesn't that mean that blkid and e2fsck can still stomp on each other if
the device is /dev/dm-0 ?

That's not in the specification, which means that for us, it's an
undocumented implementation detail.

> Maybe that explains you not seeing the flocks in the second case. Would
> the partition device names (or what their symlinks expand to?) look like
> /^dm-*/?

(For kpartx, yes it does since it uses dm to create partition devices)

But the fact that udev doesn't take the flock *at all* on dm/md/drbd
devices makes this whole proposal feel pointless.  Why would we add more
code to e2fsprogs to satisfy a locking protocol that even the supposed
benefactor doesn't follow consistently?

--D

> Regards,
> Mike Small