Bug 217529
| Summary: | Remounting ext4 filesystem from ro to rw fails when quotas are enabled | ||
|---|---|---|---|
| Product: | File System | Reporter: | Nikolas Kraetzschmar (nikolas.kraetzschmar) |
| Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | bagasdotme, chall0, marek.gresko |
| Priority: | P3 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | Subsystem: | ||
| Regression: | No | Bisected commit-id: | |
(In reply to Nikolas Kraetzschmar from comment #0) > Description > > Since commit a44be64, remounting a read-only ext4 filesystem to become > read-write fails when quotas are enabled. The mount syscall returns -EROFS > and outputs the following in dmesg: > > ``` > EXT4-fs warning (device loop0): ext4_enable_quotas:7028: Failed to enable > quota tracking (type=0, err=-30, ino=3). Please run e2fsck > ``` > > > Root cause > > The problem can be traced back to the changes introduced in commit a44be64. > It appears that the issue arises because the SB_RDONLY bit of the s_flags > field is now only cleared after executing the ext4_enable_quotas function. > However, the vfs_setup_quota_inode function, called by ext4_enable_quotas, > checks whether this bit is set (fs/quota/dquot.c:2331): > > ``` > if (IS_RDONLY(inode)) > return -EROFS; > ``` > > This condition therefore always triggers the -EROFS fail condition. > > > Steps to Reproduce > > The bug can be reproduced by executing the following script on a current > mainline kernel with defconfig: > > ``` > #!/bin/bash > > set -ex > > truncate -s 1G /tmp/img > mkfs.ext4 /tmp/img > tune2fs -Q usrquota,grpquota,prjquota /tmp/img > losetup /dev/loop0 /tmp/img > mount -o ro /dev/loop0 /mnt > mount -o remount,rw /mnt > ``` > > Executing the script results in the following output: > > ``` > + truncate -s 1G /tmp/img > + mkfs.ext4 /tmp/img > mke2fs 1.47.0 (5-Feb-2023) > Discarding device blocks: done > Creating filesystem with 262144 4k blocks and 65536 inodes > Filesystem UUID: b96a3da2-043f-11ee-b6f0-47c69db05231 > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376 > > Allocating group tables: done > Writing inode tables: done > Creating journal (8192 blocks): done > Writing superblocks and filesystem accounting information: done > > + tune2fs -Q usrquota,grpquota,prjquota /tmp/img > tune2fs 1.47.0 (5-Feb-2023) > + losetup /dev/loop0 /tmp/img > [ 6.766763] loop0: detected capacity change from 0 to 2097152 > + mount -o ro /dev/loop0 /mnt > [ 6.791561] EXT4-fs (loop0): mounted filesystem > b96a3da2-043f-11ee-b6f0-47c69db05231 ro with ordered data mode. Quota mode: > journalled. > + mount -o remount,rw /mnt > [ 6.805546] EXT4-fs warning (device loop0): ext4_enable_quotas:7028: > Failed to enable quota tracking (type=0, err=-30, ino=3). Please run e2fsck > to fix. > mount: /mnt: cannot remount /dev/loop0 read-write, is write-protected. > dmesg(1) may have more information after failed mount system call. > ``` Ted had recently sent out the proposed fixes ([1] and [2]). Please test. [1]: https://lore.kernel.org/linux-ext4/20230608141805.1434230-1-tytso@mit.edu/ [2]: https://lore.kernel.org/linux-ext4/20230608141805.1434230-2-tytso@mit.edu/ Thanks for the update, yes these fixes work fine. |
Description Since commit a44be64, remounting a read-only ext4 filesystem to become read-write fails when quotas are enabled. The mount syscall returns -EROFS and outputs the following in dmesg: ``` EXT4-fs warning (device loop0): ext4_enable_quotas:7028: Failed to enable quota tracking (type=0, err=-30, ino=3). Please run e2fsck ``` Root cause The problem can be traced back to the changes introduced in commit a44be64. It appears that the issue arises because the SB_RDONLY bit of the s_flags field is now only cleared after executing the ext4_enable_quotas function. However, the vfs_setup_quota_inode function, called by ext4_enable_quotas, checks whether this bit is set (fs/quota/dquot.c:2331): ``` if (IS_RDONLY(inode)) return -EROFS; ``` This condition therefore always triggers the -EROFS fail condition. Steps to Reproduce The bug can be reproduced by executing the following script on a current mainline kernel with defconfig: ``` #!/bin/bash set -ex truncate -s 1G /tmp/img mkfs.ext4 /tmp/img tune2fs -Q usrquota,grpquota,prjquota /tmp/img losetup /dev/loop0 /tmp/img mount -o ro /dev/loop0 /mnt mount -o remount,rw /mnt ``` Executing the script results in the following output: ``` + truncate -s 1G /tmp/img + mkfs.ext4 /tmp/img mke2fs 1.47.0 (5-Feb-2023) Discarding device blocks: done Creating filesystem with 262144 4k blocks and 65536 inodes Filesystem UUID: b96a3da2-043f-11ee-b6f0-47c69db05231 Superblock backups stored on blocks: 32768, 98304, 163840, 229376 Allocating group tables: done Writing inode tables: done Creating journal (8192 blocks): done Writing superblocks and filesystem accounting information: done + tune2fs -Q usrquota,grpquota,prjquota /tmp/img tune2fs 1.47.0 (5-Feb-2023) + losetup /dev/loop0 /tmp/img [ 6.766763] loop0: detected capacity change from 0 to 2097152 + mount -o ro /dev/loop0 /mnt [ 6.791561] EXT4-fs (loop0): mounted filesystem b96a3da2-043f-11ee-b6f0-47c69db05231 ro with ordered data mode. Quota mode: journalled. + mount -o remount,rw /mnt [ 6.805546] EXT4-fs warning (device loop0): ext4_enable_quotas:7028: Failed to enable quota tracking (type=0, err=-30, ino=3). Please run e2fsck to fix. mount: /mnt: cannot remount /dev/loop0 read-write, is write-protected. dmesg(1) may have more information after failed mount system call. ```