Hello,
On Wed 21-02-24 23:29:39, JunChao Sun wrote:
> I saw that ext4 has supported BLK_OPEN_RESTRICT_WRITES in commits
> aca740cecbe("fs: open block device after superblock creation") and
> afde134b5bd0("ext4: Block writes to journal device"). I'm not certain
> whether these commits caused the following issue.
>
> Environment:
> 6.8.0-rc3-00279-g4a7bbe7519b6-dirty(commit 4a7bbe7519b6a5).
> sjc@sjc-laptop:~/linux$ mkfs.ext4 -V
> mke2fs 1.47.0 (5-Feb-2023)
> Using EXT2FS Library version 1.47.0
> sjc@sjc-laptop:~/linux$ mount -V
> mount from util-linux 2.39.1 (libmount 2.39.1: selinux, smack, btrfs,
> verity, namespaces, idmapping, assert, debug)
>
> Problem:
> When I mounted the ext4 file system in the qemu system, I encountered
> the following error:
> root@q:~/linux# mount -t ext4 ext4.img /mnt/ext4/
> [ 848.897532] loop1: detected capacity change from 0 to 2097152
> [ 848.905535] /dev/loop1: Can't open blockdev
> mount: /mnt/ext4: /dev/loop1 already mounted or mount point busy.
> dmesg(1) may have more information after failed mount system call.
>
> I reviewed the relevant code and found that the mount program first
> calls the openat system call to open the /dev/loop1 file, followed by
> the mount system call (with /dev/loop1 as the first parameter).
>
> As for the former openat system call, it eventually reaches the chain
> of (vfs_open->do_dentry_open->blkdev_open->bdev_open_by_dev->bdev_claim_write_access).
> In bdev_claim_write_access, the following logic applies:
> /* Claim exclusive or shared write access. */
> if (mode & BLK_OPEN_RESTRICT_WRITES)
> bdev_block_writes(bdev);
> else if (mode & BLK_OPEN_WRITE)
> bdev->bd_writers++;
> The argument mode here doesn't set BLK_OPEN_RESTRICT_WRITES flag, so
> goes bdev->bd_writers++.
>
> And in the latter mount system call, the following logic is followed:
> (vfs_get_tree->get_tree_bdev->setup_bdev_super->bdev_open_by_dev->bdev_may_open).
> In bdev_may_open, the following logic applies:
> if (mode & BLK_OPEN_RESTRICT_WRITES && bdev->bd_writers > 0)
> return false;
>
> Due to the fact that the argument mode has already been set with the
> BLK_OPEN_RESTRICT_WRITES flag in the setup_bdev_super function, and
> since bdev->bd_writers is already 1 at this point, the function
> returns false. This ultimately leads to the mount system call
> returning the EBUSY error.
Yes, this is correct. How mount(8) sets up loop devices gets broken by when
BLK_OPEN_RESTRICT_WRITES is enabled.
> Is this indeed a problem, or is there a misunderstanding in my
> comprehension? If it is indeed a problem, can we resolve it by
> removing the BLK_OPEN_RESTRICT_WRITES from the sb_open_mode macro
> definition?
No. Cases like above are the reason why there's still a config option
CONFIG_BLK_DEV_WRITE_MOUNTED and it defaults to 'y'. We need to be fixing
userspace - util-linux in this case - to avoid having writeable file handle
open to block devices that are being mounted.
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
