xfs: start inodegc after quota initialization

[PATCH] xfs: start inodegc after quota initialization

Posted by Pedro Demarchi Gomes 2 months ago

When mounting a xfs filesystem with quotas, if an error occurs in xfs_mount
after calling xfs_inodegc_start and before m_quotainfo initialization, the
error path will call xfs_inodegc_flush assuming that m_quotainfo was already
initialized, causing the following error:

[   82.411853][   T23] ==================================================================
[   82.412678][   T23] BUG: KASAN: null-ptr-deref in mutex_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:4457 kernel/locking/mutex.c:159 kernel/locking/mutex.c:289)
[   82.413383][   T23] Write of size 8 at addr 0000000000000030 by task kworker/1:0/23
[   82.414187][   T23]
[   82.414450][   T23] CPU: 1 UID: 0 PID: 23 Comm: kworker/1:0 Not tainted 7.0.0-rc5-00051-gbbeb83d3182a #35 PREEMPT(
[   82.414458][   T23] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[   82.414463][   T23] Workqueue: xfs-inodegc/loop0 xfs_inodegc_worker
[   82.414478][   T23] Call Trace:
[   82.414481][   T23]  <TASK>
[   82.414484][   T23]  dump_stack_lvl (lib/dump_stack.c:122)
[   82.414494][   T23]  print_report (mm/kasan/report.c:487)
[   82.414518][   T23]  kasan_report (mm/kasan/report.c:597)
[   82.414541][   T23]  kasan_check_range (mm/kasan/generic.c:? mm/kasan/generic.c:200)
[   82.414549][   T23]  mutex_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:4457 kernel/locking/mutex.c:159 kernel/locking/mutex.c:289)
[   82.414601][   T23]  xfs_qm_dqget_cache_lookup (fs/xfs/xfs_dquot.c:813)
[   82.414609][   T23]  xfs_qm_dqget_inode (fs/xfs/xfs_dquot.c:1017)
[   82.414678][   T23]  xfs_qm_dqattach_locked (fs/xfs/xfs_qm.c:331)
[   82.414688][   T23]  xfs_qm_dqattach (fs/xfs/xfs_qm.c:371)
[   82.414696][   T23]  xfs_inactive (fs/xfs/xfs_inode.c:1453)
[   82.414733][   T23]  xfs_inodegc_worker (fs/xfs/xfs_icache.c:1946 fs/xfs/xfs_icache.c:1992)
[   82.414743][   T23]  process_scheduled_works (kernel/workqueue.c:3281 kernel/workqueue.c:3359)
[   82.414755][   T23]  worker_thread (kernel/workqueue.c:?)
[   82.414775][   T23]  kthread (kernel/kthread.c:437)
[   82.414787][   T23]  ret_from_fork (arch/x86/kernel/process.c:164)
[   82.414822][   T23]  ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
[   82.414834][   T23]  </TASK>

To avoid this, call xfs_inodegc_start after quota initialization.

Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
Closes: https://lore.kernel.org/all/DDC07F0C-05D2-46B4-9815-E010749FB3DC@gmail.com/
Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
---
 fs/xfs/xfs_mount.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
index ef1ea8a1238c..d6f75ab41337 100644
--- a/fs/xfs/xfs_mount.c
+++ b/fs/xfs/xfs_mount.c
@@ -1057,7 +1057,6 @@ xfs_mountfs(
 		xfs_clear_using_logged_xattrs(mp);
 
 	/* Enable background inode inactivation workers. */
-	xfs_inodegc_start(mp);
 	xfs_blockgc_start(mp);
 
 	if (xfs_has_metadir(mp)) {
@@ -1143,6 +1142,8 @@ xfs_mountfs(
 		}
 	}
 
+	xfs_inodegc_start(mp);
+
 	/*
 	 * Finish recovering the file system.  This part needed to be delayed
 	 * until after the root and real-time bitmap inodes were consistently
-- 
2.47.3

Re: [PATCH] xfs: start inodegc after quota initialization

Posted by Darrick J. Wong 2 months ago

On Sun, Apr 12, 2026 at 09:49:25PM -0300, Pedro Demarchi Gomes wrote:
> When mounting a xfs filesystem with quotas, if an error occurs in xfs_mount
> after calling xfs_inodegc_start and before m_quotainfo initialization, the
> error path will call xfs_inodegc_flush assuming that m_quotainfo was already
> initialized, causing the following error:
> 
> [   82.411853][   T23] ==================================================================
> [   82.412678][   T23] BUG: KASAN: null-ptr-deref in mutex_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:4457 kernel/locking/mutex.c:159 kernel/locking/mutex.c:289)
> [   82.413383][   T23] Write of size 8 at addr 0000000000000030 by task kworker/1:0/23
> [   82.414187][   T23]
> [   82.414450][   T23] CPU: 1 UID: 0 PID: 23 Comm: kworker/1:0 Not tainted 7.0.0-rc5-00051-gbbeb83d3182a #35 PREEMPT(
> [   82.414458][   T23] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> [   82.414463][   T23] Workqueue: xfs-inodegc/loop0 xfs_inodegc_worker
> [   82.414478][   T23] Call Trace:
> [   82.414481][   T23]  <TASK>
> [   82.414484][   T23]  dump_stack_lvl (lib/dump_stack.c:122)
> [   82.414494][   T23]  print_report (mm/kasan/report.c:487)
> [   82.414518][   T23]  kasan_report (mm/kasan/report.c:597)
> [   82.414541][   T23]  kasan_check_range (mm/kasan/generic.c:? mm/kasan/generic.c:200)
> [   82.414549][   T23]  mutex_lock (./include/linux/instrumented.h:55 ./include/linux/atomic/atomic-instrumented.h:4457 kernel/locking/mutex.c:159 kernel/locking/mutex.c:289)
> [   82.414601][   T23]  xfs_qm_dqget_cache_lookup (fs/xfs/xfs_dquot.c:813)
> [   82.414609][   T23]  xfs_qm_dqget_inode (fs/xfs/xfs_dquot.c:1017)
> [   82.414678][   T23]  xfs_qm_dqattach_locked (fs/xfs/xfs_qm.c:331)
> [   82.414688][   T23]  xfs_qm_dqattach (fs/xfs/xfs_qm.c:371)
> [   82.414696][   T23]  xfs_inactive (fs/xfs/xfs_inode.c:1453)
> [   82.414733][   T23]  xfs_inodegc_worker (fs/xfs/xfs_icache.c:1946 fs/xfs/xfs_icache.c:1992)
> [   82.414743][   T23]  process_scheduled_works (kernel/workqueue.c:3281 kernel/workqueue.c:3359)
> [   82.414755][   T23]  worker_thread (kernel/workqueue.c:?)
> [   82.414775][   T23]  kthread (kernel/kthread.c:437)
> [   82.414787][   T23]  ret_from_fork (arch/x86/kernel/process.c:164)
> [   82.414822][   T23]  ret_from_fork_asm (arch/x86/entry/entry_64.S:255)
> [   82.414834][   T23]  </TASK>
> 
> To avoid this, call xfs_inodegc_start after quota initialization.
> 
> Reported-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com>
> Closes: https://lore.kernel.org/all/DDC07F0C-05D2-46B4-9815-E010749FB3DC@gmail.com/
> Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes@gmail.com>
> ---
>  fs/xfs/xfs_mount.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index ef1ea8a1238c..d6f75ab41337 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -1057,7 +1057,6 @@ xfs_mountfs(
>  		xfs_clear_using_logged_xattrs(mp);
>  
>  	/* Enable background inode inactivation workers. */
> -	xfs_inodegc_start(mp);
>  	xfs_blockgc_start(mp);
>  
>  	if (xfs_has_metadir(mp)) {
> @@ -1143,6 +1142,8 @@ xfs_mountfs(
>  		}
>  	}
>  
> +	xfs_inodegc_start(mp);

Why is it correct to defer inodegc until this point?  Can any code
between line 1060 and 1145 push an inode to the inodegc mechanism?
blockgc can unmap blocks from files, so why is it ok to leave the
blockgc_start call where it is?

--D

> +
>  	/*
>  	 * Finish recovering the file system.  This part needed to be delayed
>  	 * until after the root and real-time bitmap inodes were consistently
> -- 
> 2.47.3
> 
>

Re: [PATCH] xfs: start inodegc after quota initialization

Posted by Christoph Hellwig 2 months ago

On Mon, Apr 13, 2026 at 11:09:40AM -0700, Darrick J. Wong wrote:
> > index ef1ea8a1238c..d6f75ab41337 100644
> > --- a/fs/xfs/xfs_mount.c
> > +++ b/fs/xfs/xfs_mount.c
> > @@ -1057,7 +1057,6 @@ xfs_mountfs(
> >  		xfs_clear_using_logged_xattrs(mp);
> >  
> >  	/* Enable background inode inactivation workers. */
> > -	xfs_inodegc_start(mp);
> >  	xfs_blockgc_start(mp);
> >  
> >  	if (xfs_has_metadir(mp)) {
> > @@ -1143,6 +1142,8 @@ xfs_mountfs(
> >  		}
> >  	}
> >  
> > +	xfs_inodegc_start(mp);
> 
> Why is it correct to defer inodegc until this point?  Can any code
> between line 1060 and 1145 push an inode to the inodegc mechanism?
> blockgc can unmap blocks from files, so why is it ok to leave the
> blockgc_start call where it is?

Looking at this - I think actually performing inodegc before quotas
are up sounds dangerous, as we'd miss th quota accounting.  So I
think we need to defer starting the runners after that.  But we
should support queuing up inodes before that.  blockgc has
the same issues.

Re: [PATCH] xfs: start inodegc after quota initialization

Posted by Dave Chinner 2 months ago

On Wed, Apr 15, 2026 at 12:26:11AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 13, 2026 at 11:09:40AM -0700, Darrick J. Wong wrote:
> > > index ef1ea8a1238c..d6f75ab41337 100644
> > > --- a/fs/xfs/xfs_mount.c
> > > +++ b/fs/xfs/xfs_mount.c
> > > @@ -1057,7 +1057,6 @@ xfs_mountfs(
> > >  		xfs_clear_using_logged_xattrs(mp);
> > >  
> > >  	/* Enable background inode inactivation workers. */
> > > -	xfs_inodegc_start(mp);
> > >  	xfs_blockgc_start(mp);
> > >  
> > >  	if (xfs_has_metadir(mp)) {
> > > @@ -1143,6 +1142,8 @@ xfs_mountfs(
> > >  		}
> > >  	}
> > >  
> > > +	xfs_inodegc_start(mp);
> > 
> > Why is it correct to defer inodegc until this point?  Can any code
> > between line 1060 and 1145 push an inode to the inodegc mechanism?
> > blockgc can unmap blocks from files, so why is it ok to leave the
> > blockgc_start call where it is?
> 
> Looking at this - I think actually performing inodegc before quotas
> are up sounds dangerous, as we'd miss th quota accounting.  So I
> think we need to defer starting the runners after that.  But we
> should support queuing up inodes before that.  blockgc has
> the same issues.

Chicken and egg.

inodegc has to be up before the first xfs_iget() call is made,
because releasing an inode could require inodegc to run to allow it
to be freed.

We are bringing all the metadir inodes, the root inode, the realtime
inodes, etc into memory before we start up quota. With the above in
mind, inodegc needs to be running to ensure we clean up and free all
inodes if mount fails anywhere along the path before quotas are
brought up....

-Dave.
-- 
Dave Chinner
dgc@kernel.org

Re: [PATCH] xfs: start inodegc after quota initialization

Posted by Darrick J. Wong 2 months ago

On Wed, Apr 15, 2026 at 12:26:11AM -0700, Christoph Hellwig wrote:
> On Mon, Apr 13, 2026 at 11:09:40AM -0700, Darrick J. Wong wrote:
> > > index ef1ea8a1238c..d6f75ab41337 100644
> > > --- a/fs/xfs/xfs_mount.c
> > > +++ b/fs/xfs/xfs_mount.c
> > > @@ -1057,7 +1057,6 @@ xfs_mountfs(
> > >  		xfs_clear_using_logged_xattrs(mp);
> > >  
> > >  	/* Enable background inode inactivation workers. */
> > > -	xfs_inodegc_start(mp);
> > >  	xfs_blockgc_start(mp);
> > >  
> > >  	if (xfs_has_metadir(mp)) {
> > > @@ -1143,6 +1142,8 @@ xfs_mountfs(
> > >  		}
> > >  	}
> > >  
> > > +	xfs_inodegc_start(mp);
> > 
> > Why is it correct to defer inodegc until this point?  Can any code
> > between line 1060 and 1145 push an inode to the inodegc mechanism?
> > blockgc can unmap blocks from files, so why is it ok to leave the
> > blockgc_start call where it is?
> 
> Looking at this - I think actually performing inodegc before quotas
> are up sounds dangerous, as we'd miss th quota accounting.  So I
> think we need to defer starting the runners after that.  But we
> should support queuing up inodes before that.  blockgc has
> the same issues.

Hmm.  Very very occasionally I'll see one generic/388 fail in xfs_repair
with slightly wrong quota icount.  /me wonders if this might be it?  In
theory quotacheck could be run to fix the accounting inaccuracies (ugh)
but it's probably better just to defer gc startup.

My original question ("can any code push an inode to gc...?") remains.

--D