diff mbox series

xfs: Prevent mounting with quotas in norecovery if quotacheck is needed

Message ID 20250115061840.269757-1-cem@kernel.org (mailing list archive)
State New
Headers show
Series xfs: Prevent mounting with quotas in norecovery if quotacheck is needed | expand

Commit Message

Carlos Maiolino Jan. 15, 2025, 6:18 a.m. UTC 
From: Carlos Maiolino <cem@kernel.org>

Mounting a filesystem that requires quota state changing will generate a
transaction.

We already check for a read-only device; we should do that for
norecovery too.

A quotacheck on a norecovery mount, and with the right log size, will cause
the mount process to hang on:

[<0>] xlog_grant_head_wait+0x5d/0x2a0 [xfs]
[<0>] xlog_grant_head_check+0x112/0x180 [xfs]
[<0>] xfs_log_reserve+0xe3/0x260 [xfs]
[<0>] xfs_trans_reserve+0x179/0x250 [xfs]
[<0>] xfs_trans_alloc+0x101/0x260 [xfs]
[<0>] xfs_sync_sb+0x3f/0x80 [xfs]
[<0>] xfs_qm_mount_quotas+0xe3/0x2f0 [xfs]
[<0>] xfs_mountfs+0x7ad/0xc20 [xfs]
[<0>] xfs_fs_fill_super+0x762/0xa50 [xfs]
[<0>] get_tree_bdev_flags+0x131/0x1d0
[<0>] vfs_get_tree+0x26/0xd0
[<0>] vfs_cmd_create+0x59/0xe0
[<0>] __do_sys_fsconfig+0x4e3/0x6b0
[<0>] do_syscall_64+0x82/0x160
[<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e

This is caused by a transaction running with bogus initialized head/tail

I initially hit this while running generic/050, with random log
sizes, but I managed to reproduce it reliably here with the steps
below:

mkfs.xfs -f -lsize=1025M -f -b size=4096 -m crc=1,reflink=1,rmapbt=1, -i
sparse=1 /dev/vdb2 > /dev/null
mount -o usrquota,grpquota,prjquota /dev/vdb2 /mnt
xfs_io -x -c 'shutdown -f' /mnt
umount /mnt
mount -o ro,norecovery,usrquota,grpquota,prjquota  /dev/vdb2 /mnt

Last mount hangs up

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
---
 fs/xfs/xfs_qm_bhv.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

Comments

Darrick J. Wong Jan. 15, 2025, 6:24 a.m. UTC | #1 
On Wed, Jan 15, 2025 at 07:18:32AM +0100, cem@kernel.org wrote:
> From: Carlos Maiolino <cem@kernel.org>
> 
> Mounting a filesystem that requires quota state changing will generate a
> transaction.
> 
> We already check for a read-only device; we should do that for
> norecovery too.
> 
> A quotacheck on a norecovery mount, and with the right log size, will cause
> the mount process to hang on:
> 
> [<0>] xlog_grant_head_wait+0x5d/0x2a0 [xfs]
> [<0>] xlog_grant_head_check+0x112/0x180 [xfs]
> [<0>] xfs_log_reserve+0xe3/0x260 [xfs]
> [<0>] xfs_trans_reserve+0x179/0x250 [xfs]
> [<0>] xfs_trans_alloc+0x101/0x260 [xfs]
> [<0>] xfs_sync_sb+0x3f/0x80 [xfs]
> [<0>] xfs_qm_mount_quotas+0xe3/0x2f0 [xfs]
> [<0>] xfs_mountfs+0x7ad/0xc20 [xfs]
> [<0>] xfs_fs_fill_super+0x762/0xa50 [xfs]
> [<0>] get_tree_bdev_flags+0x131/0x1d0
> [<0>] vfs_get_tree+0x26/0xd0
> [<0>] vfs_cmd_create+0x59/0xe0
> [<0>] __do_sys_fsconfig+0x4e3/0x6b0
> [<0>] do_syscall_64+0x82/0x160
> [<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> 
> This is caused by a transaction running with bogus initialized head/tail
> 
> I initially hit this while running generic/050, with random log
> sizes, but I managed to reproduce it reliably here with the steps
> below:
> 
> mkfs.xfs -f -lsize=1025M -f -b size=4096 -m crc=1,reflink=1,rmapbt=1, -i
> sparse=1 /dev/vdb2 > /dev/null
> mount -o usrquota,grpquota,prjquota /dev/vdb2 /mnt
> xfs_io -x -c 'shutdown -f' /mnt
> umount /mnt
> mount -o ro,norecovery,usrquota,grpquota,prjquota  /dev/vdb2 /mnt
> 
> Last mount hangs up
> 
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
>  fs/xfs/xfs_qm_bhv.c | 12 +++++++-----
>  1 file changed, 7 insertions(+), 5 deletions(-)
> 
> diff --git a/fs/xfs/xfs_qm_bhv.c b/fs/xfs/xfs_qm_bhv.c
> index 37f1230e7584..eae106ca7e1b 100644
> --- a/fs/xfs/xfs_qm_bhv.c
> +++ b/fs/xfs/xfs_qm_bhv.c
> @@ -97,10 +97,11 @@ xfs_qm_newmount(
>  	}
>  
>  	/*
> -	 * If the device itself is read-only, we can't allow
> -	 * the user to change the state of quota on the mount -
> -	 * this would generate a transaction on the ro device,
> -	 * which would lead to an I/O error and shutdown
> +	 * If the device itself is read-only and/or in norecovery
> +	 * mode, we can't allow the user to change the state of
> +	 * quota on the mount - this would generate a transaction
> +	 * on the ro device, which would lead to an I/O error and
> +	 * shutdown.
>  	 */
>  
>  	if (((uquotaondisk && !XFS_IS_UQUOTA_ON(mp)) ||
> @@ -109,7 +110,8 @@ xfs_qm_newmount(
>  	    (!gquotaondisk &&  XFS_IS_GQUOTA_ON(mp)) ||
>  	     (pquotaondisk && !XFS_IS_PQUOTA_ON(mp)) ||
>  	    (!pquotaondisk &&  XFS_IS_PQUOTA_ON(mp)))  &&
> -	    xfs_dev_is_read_only(mp, "changing quota state")) {
> +	    (xfs_dev_is_read_only(mp, "changing quota state") ||
> +	     xfs_has_norecovery(mp))) {
>  		xfs_warn(mp, "please mount with%s%s%s%s.",
>  			(!quotaondisk ? "out quota" : ""),
>  			(uquotaondisk ? " usrquota" : ""),

The logic seems ok, but (as I mentioned in office hours this morning) I
wonder if we shouldn't just ignore quota entirely for a norecovery
mount?

I guess for metadir we also could change the message to say "don't mount
with any quota options" since the quota mount options are persistent now.

--D

> -- 
> 2.47.1
>
Carlos Maiolino Jan. 15, 2025, 6:32 a.m. UTC | #2 
On Tue, Jan 14, 2025 at 10:24:38PM -0800, Darrick J. Wong wrote:
> On Wed, Jan 15, 2025 at 07:18:32AM +0100, cem@kernel.org wrote:
> > From: Carlos Maiolino <cem@kernel.org>
> > 
> > Mounting a filesystem that requires quota state changing will generate a
> > transaction.
> > 
> > We already check for a read-only device; we should do that for
> > norecovery too.
> > 
> > A quotacheck on a norecovery mount, and with the right log size, will cause
> > the mount process to hang on:
> > 
> > [<0>] xlog_grant_head_wait+0x5d/0x2a0 [xfs]
> > [<0>] xlog_grant_head_check+0x112/0x180 [xfs]
> > [<0>] xfs_log_reserve+0xe3/0x260 [xfs]
> > [<0>] xfs_trans_reserve+0x179/0x250 [xfs]
> > [<0>] xfs_trans_alloc+0x101/0x260 [xfs]
> > [<0>] xfs_sync_sb+0x3f/0x80 [xfs]
> > [<0>] xfs_qm_mount_quotas+0xe3/0x2f0 [xfs]
> > [<0>] xfs_mountfs+0x7ad/0xc20 [xfs]
> > [<0>] xfs_fs_fill_super+0x762/0xa50 [xfs]
> > [<0>] get_tree_bdev_flags+0x131/0x1d0
> > [<0>] vfs_get_tree+0x26/0xd0
> > [<0>] vfs_cmd_create+0x59/0xe0
> > [<0>] __do_sys_fsconfig+0x4e3/0x6b0
> > [<0>] do_syscall_64+0x82/0x160
> > [<0>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > 
> > This is caused by a transaction running with bogus initialized head/tail
> > 
> > I initially hit this while running generic/050, with random log
> > sizes, but I managed to reproduce it reliably here with the steps
> > below:
> > 
> > mkfs.xfs -f -lsize=1025M -f -b size=4096 -m crc=1,reflink=1,rmapbt=1, -i
> > sparse=1 /dev/vdb2 > /dev/null
> > mount -o usrquota,grpquota,prjquota /dev/vdb2 /mnt
> > xfs_io -x -c 'shutdown -f' /mnt
> > umount /mnt
> > mount -o ro,norecovery,usrquota,grpquota,prjquota  /dev/vdb2 /mnt
> > 
> > Last mount hangs up
> > 
> > Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> > ---
> >  fs/xfs/xfs_qm_bhv.c | 12 +++++++-----
> >  1 file changed, 7 insertions(+), 5 deletions(-)
> > 
> > diff --git a/fs/xfs/xfs_qm_bhv.c b/fs/xfs/xfs_qm_bhv.c
> > index 37f1230e7584..eae106ca7e1b 100644
> > --- a/fs/xfs/xfs_qm_bhv.c
> > +++ b/fs/xfs/xfs_qm_bhv.c
> > @@ -97,10 +97,11 @@ xfs_qm_newmount(
> >  	}
> >  
> >  	/*
> > -	 * If the device itself is read-only, we can't allow
> > -	 * the user to change the state of quota on the mount -
> > -	 * this would generate a transaction on the ro device,
> > -	 * which would lead to an I/O error and shutdown
> > +	 * If the device itself is read-only and/or in norecovery
> > +	 * mode, we can't allow the user to change the state of
> > +	 * quota on the mount - this would generate a transaction
> > +	 * on the ro device, which would lead to an I/O error and
> > +	 * shutdown.
> >  	 */
> >  
> >  	if (((uquotaondisk && !XFS_IS_UQUOTA_ON(mp)) ||
> > @@ -109,7 +110,8 @@ xfs_qm_newmount(
> >  	    (!gquotaondisk &&  XFS_IS_GQUOTA_ON(mp)) ||
> >  	     (pquotaondisk && !XFS_IS_PQUOTA_ON(mp)) ||
> >  	    (!pquotaondisk &&  XFS_IS_PQUOTA_ON(mp)))  &&
> > -	    xfs_dev_is_read_only(mp, "changing quota state")) {
> > +	    (xfs_dev_is_read_only(mp, "changing quota state") ||
> > +	     xfs_has_norecovery(mp))) {
> >  		xfs_warn(mp, "please mount with%s%s%s%s.",
> >  			(!quotaondisk ? "out quota" : ""),
> >  			(uquotaondisk ? " usrquota" : ""),
> 
> The logic seems ok, but (as I mentioned in office hours this morning) I
> wonder if we shouldn't just ignore quota entirely for a norecovery
> mount?

I gave it a thought. It might work, but, if there are no changes to be made, I
don't see a problem in mounting with quotas and let user browse quota data.

> 
> I guess for metadir we also could change the message to say "don't mount
> with any quota options" since the quota mount options are persistent now.

No complains about it :)
diff mbox series

Patch

diff --git a/fs/xfs/xfs_qm_bhv.c b/fs/xfs/xfs_qm_bhv.c
index 37f1230e7584..eae106ca7e1b 100644
--- a/fs/xfs/xfs_qm_bhv.c
+++ b/fs/xfs/xfs_qm_bhv.c
@@ -97,10 +97,11 @@  xfs_qm_newmount(
 	}
 
 	/*
-	 * If the device itself is read-only, we can't allow
-	 * the user to change the state of quota on the mount -
-	 * this would generate a transaction on the ro device,
-	 * which would lead to an I/O error and shutdown
+	 * If the device itself is read-only and/or in norecovery
+	 * mode, we can't allow the user to change the state of
+	 * quota on the mount - this would generate a transaction
+	 * on the ro device, which would lead to an I/O error and
+	 * shutdown.
 	 */
 
 	if (((uquotaondisk && !XFS_IS_UQUOTA_ON(mp)) ||
@@ -109,7 +110,8 @@  xfs_qm_newmount(
 	    (!gquotaondisk &&  XFS_IS_GQUOTA_ON(mp)) ||
 	     (pquotaondisk && !XFS_IS_PQUOTA_ON(mp)) ||
 	    (!pquotaondisk &&  XFS_IS_PQUOTA_ON(mp)))  &&
-	    xfs_dev_is_read_only(mp, "changing quota state")) {
+	    (xfs_dev_is_read_only(mp, "changing quota state") ||
+	     xfs_has_norecovery(mp))) {
 		xfs_warn(mp, "please mount with%s%s%s%s.",
 			(!quotaondisk ? "out quota" : ""),
 			(uquotaondisk ? " usrquota" : ""),