From: Dave Chinner <dgc@kernel.org>
To: ZhengYuan Huang <gality369@gmail.com>
Cc: cem@kernel.org, dchinner@redhat.com, djwong@kernel.org,
linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
baijiaju1990@gmail.com, r33s3n6@gmail.com, zzzccc427@gmail.com
Subject: Re: [PATCH] xfs: avoid inodegc worker flush deadlock
Date: Mon, 30 Mar 2026 12:41:29 +1100 [thread overview]
Message-ID: <acnUybgMAsBA9IEc@dread> (raw)
In-Reply-To: <20260328071252.3936506-1-gality369@gmail.com>
On Sat, Mar 28, 2026 at 03:12:51PM +0800, ZhengYuan Huang wrote:
> [BUG]
> WARNING: possible recursive locking detected
> --------------------------------------------
> kworker/0:1/10 is trying to acquire lock:
> ffff88801621fd48 ((wq_completion)xfs-inodegc/ublkb1){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x99/0x1c0 kernel/workqueue.c:3936
>
> but task is already holding lock:
> ffff88801621fd48 ((wq_completion)xfs-inodegc/ublkb1){+.+.}-{0:0}, at: process_one_work+0x1188/0x1980 kernel/workqueue.c:3238
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
> ----
> lock((wq_completion)xfs-inodegc/ublkb1);
> lock((wq_completion)xfs-inodegc/ublkb1);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 2 locks held by kworker/0:1/10:
> #0: ffff88801621fd48 ((wq_completion)xfs-inodegc/ublkb1){+.+.}-{0:0}, at: process_one_work+0x1188/0x1980 kernel/workqueue.c:3238
> #1: ffff888009dafce8 ((work_completion)(&(&gc->work)->work)){+.+.}-{0:0}, at: process_one_work+0x865/0x1980 kernel/workqueue.c:3239
>
> stack backtrace:
> Workqueue: xfs-inodegc/ublkb1 xfs_inodegc_worker
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0xbe/0x130 lib/dump_stack.c:120
> dump_stack+0x15/0x20 lib/dump_stack.c:129
> print_deadlock_bug+0x23f/0x320 kernel/locking/lockdep.c:3041
> check_deadlock kernel/locking/lockdep.c:3093 [inline]
> validate_chain kernel/locking/lockdep.c:3895 [inline]
> __lock_acquire+0x1317/0x21e0 kernel/locking/lockdep.c:5237
> lock_acquire kernel/locking/lockdep.c:5868 [inline]
> lock_acquire+0x169/0x2f0 kernel/locking/lockdep.c:5825
> touch_wq_lockdep_map+0xab/0x1c0 kernel/workqueue.c:3936
> __flush_workqueue+0x117/0x1010 kernel/workqueue.c:3978
> xfs_inodegc_wait_all fs/xfs/xfs_icache.c:495 [inline]
> xfs_inodegc_flush+0x9a/0x390 fs/xfs/xfs_icache.c:2020
> xfs_blockgc_flush_all+0x106/0x250 fs/xfs/xfs_icache.c:1614
> xfs_trans_alloc+0x5e4/0xc10 fs/xfs/xfs_trans.c:268
> xfs_inactive_ifree+0x329/0x3c0 fs/xfs/xfs_inode.c:1224
> xfs_inactive+0x590/0xb60 fs/xfs/xfs_inode.c:1485
How did the filesystem get to ENOSPC when freeing an inode?
That should not happen, so can you please describe what the system
was doing to trip over this issue?
i.e. the problem that needs to be understood and fixed here is
"freeing an inode should never see ENOSPC", not "inodegc should not
recurse"...
-Dave.
--
Dave Chinner
dgc@kernel.org
next prev parent reply other threads:[~2026-03-30 1:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-28 7:12 [PATCH] xfs: avoid inodegc worker flush deadlock ZhengYuan Huang
2026-03-30 1:41 ` Dave Chinner [this message]
2026-03-30 2:40 ` ZhengYuan Huang
2026-03-30 20:45 ` Dave Chinner
2026-03-31 3:24 ` ZhengYuan Huang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=acnUybgMAsBA9IEc@dread \
--to=dgc@kernel.org \
--cc=baijiaju1990@gmail.com \
--cc=cem@kernel.org \
--cc=dchinner@redhat.com \
--cc=djwong@kernel.org \
--cc=gality369@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=r33s3n6@gmail.com \
--cc=zzzccc427@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox