Re: [PATCH RFC v2 08/18] fs: add dedicated block device open helpers for filesystems

[Christian Brauner]

On Tue, Sep 01, 2026 at 03:13:14PM -0700, Darrick J. Wong wrote:
> On Tue, Jun 16, 2026 at 04:08:24PM +0200, Christian Brauner wrote:
> > Add fs_bdev_file_open_by_{dev,path}() and fs_bdev_file_release(). They
> > open the device with fs_holder_ops and register a claim in the
> > device-to-superblock table. Claims on the same (device, superblock)
> > pair share one entry, so when a filesystem claims a device it already
> > uses (xfs with its log on the data device), no second entry is added
> > and each superblock will be acted on once.
> > 
> > The holder argument remains purely the block layer's exclusivity token:
> > a superblock, or a file_system_type for a device shared by several
> > superblocks of that type. The shared case only becomes usable once the
> > fs_holder_ops callbacks resolve superblocks through the table instead
> > of bdev->bd_holder.
> > 
> > Convert the main device, setup_bdev_super() and kill_block_super(),
> > over: the open finds the entry registered by sget_fc() and claims it
> > again. cramfs and romfs bypass kill_block_super() so they can handle
> > MTD mounts and release the main device with a plain bdev_fput(), which
> > would leave the claim behind: the (dev, sb) entry would never be
> > unregistered and the passive reference it holds would keep the
> > superblock alive forever. Convert their release paths in the same
> > step.
> > 
> > The frozen-device check stays in setup_bdev_super() for the primary
> > device and is added to fs_bdev_register() for new claims, i.e. every
> > additional device a filesystem opens through the helpers. Only a
> > (device, superblock) pair the superblock claimed earlier may be
> > reopened while frozen (xfs with its log on the data device): the freeze
> > already covers that superblock through the existing claim, so nothing
> > escapes it. Without the setup_bdev_super() check a device frozen before
> > the mount even started (dm lock_fs, loop) could be mounted and written
> > to (journal replay) under an active freeze, because the primary open
> > reuses the entry registered by sget_fc() and never takes the new-claim
> > path.
> > 
> > Both checks read bd_fsfreeze_count only after the entry is published
> > (by sget_fc() for the primary, by fs_bdev_register() for new claims)
> > and pair with bdev_freeze() incrementing the count before walking the
> > table: either the mount sees the elevated freeze count and fails with
> > EBUSY, or the freeze finds the published entry and converges once
> > SB_BORN is set.
> 
> Hmm.  I /think/ this might be causing regressions in xfs/006,
> generic/311, and xfs/264 on XFS realtime filesystems.  Each test fails
> with a mount failure due to a busy device:
> 
>  --- /run/fstests/bin/tests/xfs/006.out	2025-07-15 14:41:40.170403463 -0700
>  +++ /run/fstests/logs/xfs/006.out.bad	2026-08-31 12:25:01.790239078 -0700
>  @@ -6,3 +6,7 @@ error/metadata/EIO/max_retries=-1
>   error/metadata/EIO/retry_timeout_seconds=-1
>   error/metadata/ENOSPC/max_retries=-1
>   error/metadata/ENOSPC/retry_timeout_seconds=-1
>  +mount: /mnt/s: /dev/mapper/error-test.006 already mounted or mount point busy.
>  +       dmesg(1) may have more information after failed mount system call.
>  +umount.nfs: remote share not in 'host:dir' format
>  +umount.nfs: /mnt/s: not mounted
> 
> I'm not sure what's going on here, but dmesg has this to say:
> 
> XFS (dm-0): Invalid device [/dev/mapper/error-rttest.006], error=-16
> 
> So my guess is that the SCRATCH_RT volume isn't getting unfrozen
> properly?

That's a pre-existing that this series just made obvious and is fixed by:

fe967191e585 ("fs: don't return -EINVAL for successful nested thaw")

The realtime dm device doesn't get unfrozen after a lockfs
suspend/resume cycle.

So xfs/006, xfs/264, and generic/311 wrap the rt device in its own
flakey device. That suspends data then rt with lockfs and resume rt then
data. So the rt thaw is a nested thaw.

A nested thaw drops the reference but thaw_super_locked() still returns
its -EINVAL because it's still frozen. So bdev_thaw() keeps the count on
error and dm unlock_fs() ignores the result.

That's been broken since 7366f8b6fc6a8. Before this series it was merely
silent on the rt device. We properly refuse mounting devices that are
frozen not just the main device.

And it also meant a second lockfs suspend of a leaked rt device never
froze the filesystem at all...