Re: Lockdep circular dependency: btrfs_swap_activate() calls sysfs_notify()
From: Qu Wenruo
Date: Fri Jul 31 2026 - 07:12:45 EST
在 2026/7/31 20:27, Christian Borntraeger 写道:
One or more of the following files ( btrfs-swapon-kernfs-repro.sh ) violates IBM policy and all attachment(s) have been removed from the message.
If the bash script, as an attachment, violates the policy, can you just paste the content as a reply?
As I still have some uncertainty on the LLM explanation.
A concrete reproducer would allow us to do our own experiments and get everything more clear.
Otherwise really appreciated all your reports, no matter if it's generated by LLM or not, as so far your reports are 100% real bugs.
Thanks,
Qu
**********************************************************************
We had the calltrace at the bottom of this mail in our CI logs
I also attached an AI generated reproducer that triggers this easily.
For convenience, here is what AI came up with analysing the log, but
I would like your take on it. Let me know if you want to see the
AI proposed fix.
----
btrfs_swap_activate() takes the inode's i_mmap_lock for write very
early (inode.c:10120) and holds it across the entire function; the
comment there explains the intent, which is to keep mmap writes from
racing with the delalloc flush and the extent range lock.
There are three btrfs_exclop_finish() calls inside that window:
fs/btrfs/inode.c:10181 error path, swapfile on a rw subvolume
with an active snapshot
fs/btrfs/inode.c:10202 error path, could not lock the snapshot drew
lock
fs/btrfs/inode.c:10399 the common "out:" path -- taken on both
success and failure
and btrfs_exclop_finish() (fs/btrfs/fs.c:224) ends with an unconditional
sysfs_notify(). So the offending edge is taken on *every* successful
swapon of a btrfs swap file, not only on an error path.
The sysfs_notify() itself does nothing but a kernfs lookup plus a poll
wakeup for userspace watching the "exclusive_operation" attribute. It
has no dependency whatsoever on i_mmap_lock, or on the inode at all.
Both kernfs_rwsem acquisitions in the cycle are read acquisitions
({++++}), so the two of them alone cannot deadlock. A real hang needs a
third task waiting to take kernfs_rwsem for write, because rwsem
write-fairness makes a later down_read() block behind a queued writer:
T_swapon: holds i_mmap_lock(write)
blocks in down_read(kernfs_rwsem) [queued behind T_w]
T_w: blocks in down_write(kernfs_rwsem) [waiting for T_dir]
e.g. any sysfs node create/remove -- device hotplug,
module load, cgroup or block-device attribute changes
T_dir: holds kernfs_rwsem(read) in kernfs_fop_readdir
faults on the user dirent buffer -> mmap_lock
-> btrfs_page_mkwrite -> down_read(i_mmap_lock)
blocks behind T_swapon's write holder
-> three-way deadlock.
That is a narrow race, which is consistent with this having gone
unnoticed for years, but every step of it is ordinary system activity.
The dependency is genuine and worth fixing rather than annotating away.
Suggested fix is to get the sysfs_notify() out from under i_mmap_lock
real life log found in our CI:
----------------------------
LOCKDEP_CIRCULAR (suite: tela-distro, case: tests/test_mempig/test_mempig)
WARNING: possible circular locking dependency detected
7.2.0-20260730.rc5.git10.af7a8a7752eb.300.fc44.s390x+debug #1 Not tainted
------------------------------------------------------
swapon/172010 is trying to acquire lock:
000002ea80a485a0 (&root->kernfs_rwsem){++++}-{3:3}, at: kernfs_find_and_get_ns+0x3c/0x80
but task is already holding lock:
000002ebc465d270 (&ei->i_mmap_lock){++++}-{3:3}, at: btrfs_swap_activate+0x9a/0x1240
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #3 (&ei->i_mmap_lock){++++}-{3:3}:
lock_acquire+0x150/0x3f0
down_read+0x5a/0x280
btrfs_page_mkwrite+0x258/0x870
do_page_mkwrite+0x60/0x160
do_wp_page+0x128/0x750
__handle_mm_fault+0x1be/0x590
handle_mm_fault+0xa2/0x370
do_exception+0x292/0x590
__do_pgm_check+0x168/0x430
pgm_check_handler+0x114/0x160
-> #2 (sb_pagefaults){.+.+}-{0:0}:
lock_acquire+0x150/0x3f0
percpu_down_read_internal.constprop.0+0x54/0x120
btrfs_page_mkwrite+0xa6/0x870
do_page_mkwrite+0x60/0x160
do_fault+0x132/0x4a0
__handle_mm_fault+0x1be/0x590
handle_mm_fault+0xa2/0x370
do_exception+0x1a0/0x590
__do_pgm_check+0x168/0x430
pgm_check_handler+0x114/0x160
-> #1 (&mm->mmap_lock){++++}-{3:3}:
lock_acquire+0x150/0x3f0
__might_fault+0x7a/0xa0
filldir64+0x11c/0x210
kernfs_fop_readdir+0x150/0x4c0
iterate_dir+0xcc/0x2d0
__do_sys_getdents64+0x7a/0x130
__do_syscall+0x172/0x750
system_call+0x72/0x90
-> #0 (&root->kernfs_rwsem){++++}-{3:3}:
check_prev_add+0x160/0xf40
__lock_acquire+0x12aa/0x15a0
lock_acquire+0x150/0x3f0
down_read+0x5a/0x280
kernfs_find_and_get_ns+0x3c/0x80
sysfs_notify+0x60/0xc0
btrfs_swap_activate+0x83c/0x1240
__do_sys_swapon+0x278/0x9c0
__do_syscall+0x172/0x750
system_call+0x72/0x90
other info that might help us debug this:
Chain exists of:
&root->kernfs_rwsem --> sb_pagefaults --> &ei->i_mmap_lock
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&ei->i_mmap_lock);
lock(sb_pagefaults);
lock(&ei->i_mmap_lock);
rlock(&root->kernfs_rwsem);
*** DEADLOCK ***
2 locks held by swapon/172010:
#0: 000002ebc465d3f0 (&sb->s_type->i_mutex_key#20){++++}-{3:3}, at: __do_sys_swapon+0x5be/0x9c0
#1: 000002ebc465d270 (&ei->i_mmap_lock){++++}-{3:3}, at: btrfs_swap_activate+0x9a/0x1240
stack backtrace:
CPU: 6 UID: 0 PID: 172010 Comm: swapon Not tainted 7.2.0-20260730.rc5.git10.af7a8a7752eb.300.fc44.s390x+debug #1 PREEMPT
Hardware name: IBM 8561 T01 701 (z/VM 7.4.0)
Call Trace:
[<000003f7d5ab4e3e>] dump_stack_lvl+0xae/0x108
[<000003f7d5bbef24>] print_circular_bug+0x1a4/0x230
[<000003f7d5bbf13c>] check_noncircular+0x18c/0x1b0
[<000003f7d5bc0510>] check_prev_add+0x160/0xf40
[<000003f7d5bc408a>] __lock_acquire+0x12aa/0x15a0
[<000003f7d5bc44d0>] lock_acquire+0x150/0x3f0
[<000003f7d6c447ca>] down_read+0x5a/0x280
[<000003f7d60ad61c>] kernfs_find_and_get_ns+0x3c/0x80
[<000003f7d60b3b70>] sysfs_notify+0x60/0xc0
[<000003f7d635653c>] btrfs_swap_activate+0x83c/0x1240
[<000003f7d5f1d268>] __do_sys_swapon+0x278/0x9c0
[<000003f7d6c369a2>] __do_syscall+0x172/0x750
[<000003f7d6c4baa2>] system_call+0x72/0x90
INFO: lockdep is turned off.