[PATCH AUTOSEL 6.19-5.15] btrfs: don't take device_list_mutex when querying zone info

Sasha Levin
2026-03-24T11:19:57Z

From: Johannes Thumshirn <johannes.thumshirn@wdc.com>

[ Upstream commit 77603ab10429fe713a03345553ca8dbbfb1d91c6 ]

Shin'ichiro reported sporadic hangs when running generic/013 in our CI
system. When enabling lockdep, there is a lockdep splat when calling
btrfs_get_dev_zone_info_all_devices() in the mount path that can be
triggered by i.e. generic/013:

======================================================
WARNING: possible circular locking dependency detected
7.0.0-rc1+ #355 Not tainted
------------------------------------------------------
mount/1043 is trying to acquire lock:
ffff8881020b5470 (&vblk->vdev_mutex){+.+.}-{4:4}, at: virtblk_report_zones+0xda/0x430

but task is already holding lock:
ffff888102a738e0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: btrfs_get_dev_zone_info_all_devices+0x45/0x90

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #4 (&fs_devs->device_list_mutex){+.+.}-{4:4}:
__mutex_lock+0xa3/0x1360
btrfs_create_pending_block_groups+0x1f4/0x9d0
__btrfs_end_transaction+0x3e/0x2e0
btrfs_zoned_reserve_data_reloc_bg+0x2f8/0x390
open_ctree+0x1934/0x23db
btrfs_get_tree.cold+0x105/0x26c
vfs_get_tree+0x28/0xb0
__do_sys_fsconfig+0x324/0x680
do_syscall_64+0x92/0x4f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #3 (btrfs_trans_num_extwriters){++++}-{0:0}:
join_transaction+0xc2/0x5c0
start_transaction+0x17c/0xbc0
btrfs_zoned_reserve_data_reloc_bg+0x2b4/0x390
open_ctree+0x1934/0x23db
btrfs_get_tree.cold+0x105/0x26c
vfs_get_tree+0x28/0xb0
__do_sys_fsconfig+0x324/0x680
do_syscall_64+0x92/0x4f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #2 (btrfs_trans_num_writers){++++}-{0:0}:
lock_release+0x163/0x4b0
__btrfs_end_transaction+0x1c7/0x2e0
btrfs_dirty_inode+0x6f/0xd0
touch_atime+0xe5/0x2c0
btrfs_file_mmap_prepare+0x65/0x90
__mmap_region+0x4b9/0xf00
mmap_region+0xf7/0x120
do_mmap+0x43d/0x610
vm_mmap_pgoff+0xd6/0x190
ksys_mmap_pgoff+0x7e/0xc0
do_syscall_64+0x92/0x4f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #1 (&mm->mmap_lock){++++}-{4:4}:
__might_fault+0x68/0xa0
_copy_to_user+0x22/0x70
blkdev_copy_zone_to_user+0x22/0x40
virtblk_report_zones+0x282/0x430
blkdev_report_zones_ioctl+0xfd/0x130
blkdev_ioctl+0x20f/0x2c0
__x64_sys_ioctl+0x86/0xd0
do_syscall_64+0x92/0x4f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e

-> #0 (&vblk->vdev_mutex){+.+.}-{4:4}:
__lock_acquire+0x1522/0x2680
lock_acquire+0xd5/0x2f0
__mutex_lock+0xa3/0x1360
virtblk_report_zones+0xda/0x430
blkdev_report_zones_cached+0x162/0x190
btrfs_get_dev_zones+0xdc/0x2e0
btrfs_get_dev_zone_info+0x219/0xe80
btrfs_get_dev_zone_info_all_devices+0x62/0x90
open_ctree+0x1200/0x23db
btrfs_get_tree.cold+0x105/0x26c
vfs_get_tree+0x28/0xb0
__do_sys_fsconfig+0x324/0x680
do_syscall_64+0x92/0x4f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e

other info that might help us debug this:

Chain exists of:
&vblk->vdev_mutex --> btrfs_trans_num_extwriters --> &fs_devs->device_list_mutex

Possible unsafe locking scenario:

CPU0 CPU1
---- ----
lock(&fs_devs->device_list_mutex);
lock(btrfs_trans_num_extwriters);
lock(&fs_devs->device_list_mutex);
lock(&vblk->vdev_mutex);

*** DEADLOCK ***

3 locks held by mount/1043:
#0: ffff88811063e878 (&fc->uapi_mutex){+.+.}-{4:4}, at: __do_sys_fsconfig+0x2ae/0x680
#1: ffff88810cb9f0e8 (&type->s_umount_key#31/1){+.+.}-{4:4}, at: alloc_super+0xc0/0x3e0
#2: ffff888102a738e0 (&fs_devs->device_list_mutex){+.+.}-{4:4}, at: btrfs_get_dev_zone_info_all_devices+0x45/0x90

stack backtrace:
CPU: 2 UID: 0 PID: 1043 Comm: mount Not tainted 7.0.0-rc1+ #355 PREEMPT(full)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-9.fc43 06/10/2025
Call Trace:
<TASK>
dump_stack_lvl+0x5b/0x80
print_circular_bug.cold+0x18d/0x1d8
check_noncircular+0x10d/0x130
__lock_acquire+0x1522/0x2680
? vmap_small_pages_range_noflush+0x3ef/0x820
lock_acquire+0xd5/0x2f0
? virtblk_report_zones+0xda/0x430
? lock_is_held_type+0xcd/0x130
__mutex_lock+0xa3/0x1360
? virtblk_report_zones+0xda/0x430
? virtblk_report_zones+0xda/0x430
? __pfx_copy_zone_info_cb+0x10/0x10
? virtblk_report_zones+0xda/0x430
virtblk_report_zones+0xda/0x430
? __pfx_copy_zone_info_cb+0x10/0x10
blkdev_report_zones_cached+0x162/0x190
? __pfx_copy_zone_info_cb+0x10/0x10
btrfs_get_dev_zones+0xdc/0x2e0
btrfs_get_dev_zone_info+0x219/0xe80
btrfs_get_dev_zone_info_all_devices+0x62/0x90
open_ctree+0x1200/0x23db
btrfs_get_tree.cold+0x105/0x26c
? rcu_is_watching+0x18/0x50
vfs_get_tree+0x28/0xb0
__do_sys_fsconfig+0x324/0x680
do_syscall_64+0x92/0x4f0
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f615e27a40e
RSP: 002b:00007fff11b18fb8 EFLAGS: 00000246 ORIG_RAX: 00000000000001af
RAX: ffffffffffffffda RBX: 000055572e92ab10 RCX: 00007f615e27a40e
RDX: 0000000000000000 RSI: 0000000000000006 RDI: 0000000000000003
RBP: 00007fff11b19100 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000055572e92bc40 R14: 00007f615e3faa60 R15: 000055572e92bd08
</TASK>

Don't hold the device_list_mutex while calling into
btrfs_get_dev_zone_info() in btrfs_get_dev_zone_info_all_devices() to
mitigate the issue. This is safe, as no other thread can touch the device
list at the moment of execution.

Reported-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have sufficient information to complete the full analysis. Let me
compile the results.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

### Step 1.1: Subject Line
- **Subsystem**: btrfs (zoned)
- **Action verb**: "don't take" — removing an unnecessary/harmful lock,
indicates a deadlock fix
- **Summary**: Remove device_list_mutex from zone info query to fix
circular lock dependency

### Step 1.2: Tags
- **Reported-by**: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com> —
real user/tester report of sporadic hangs
- **Reviewed-by**: Damien Le Moal <dlemoal@kernel.org> — block
layer/zoned storage expert
- **Reviewed-by**: David Sterba <dsterba@suse.com> — btrfs maintainer
- **Signed-off-by**: Johannes Thumshirn <johannes.thumshirn@wdc.com> —
author, btrfs/zoned regular contributor
- **Signed-off-by**: David Sterba <dsterba@suse.com> — btrfs maintainer
acceptance
- **No Fixes: tag** (expected for manual review candidates)
- **No Cc: stable** (expected)

### Step 1.3: Commit Body
The commit describes sporadic hangs found by a CI system running
generic/013. Lockdep confirms a circular locking dependency:
- Chain: `device_list_mutex` → `vblk->vdev_mutex` → `mmap_lock` →
`btrfs_trans_num_writers` → `btrfs_trans_num_extwriters` →
`device_list_mutex`
- Full stack traces provided showing the exact lock acquisition paths
- Clear reproduction: mount of zoned btrfs filesystem (open_ctree path)

### Step 1.4: Hidden Bug Fix Detection
This is explicitly a deadlock fix. The commit message directly shows the
lockdep splat and the deadlock scenario. Not hidden at all.

**Record**: Real deadlock fix. Sporadic hangs during mount. Confirmed by
lockdep with full dependency chain.

---

## PHASE 2: DIFF ANALYSIS

### Step 2.1: Inventory
- **Files changed**: 1 — `fs/btrfs/zoned.c`
- **Lines**: -2 (mutex_lock/mutex_unlock removed), +4 (comment added)
- **Net**: +2 lines
- **Functions modified**: `btrfs_get_dev_zone_info_all_devices()`
- **Scope**: Single-file, single-function, surgical fix

### Step 2.2: Code Flow Change
- **Before**: The function acquires `device_list_mutex` before iterating
the device list and releases it after
- **After**: The function iterates the device list without the mutex,
relying on the fact that during mount (open_ctree), no other thread
can modify the device list

### Step 2.3: Bug Mechanism
**Category**: Deadlock / circular lock dependency (CRITICAL)
- The lock creates a dependency chain that can deadlock with other paths
that acquire these locks in different order
- CPU0 holds `device_list_mutex` and needs `vblk->vdev_mutex`
- CPU1 holds locks in the transaction path that eventually need
`device_list_mutex`

### Step 2.4: Fix Quality
- **Obviously correct**: Yes — during `open_ctree()`, the filesystem is
being mounted, no other thread can add/remove devices
- **Minimal/surgical**: Yes — only removes the unnecessary lock, adds
explanatory comment
- **Regression risk**: Very low — the lock was unnecessary at this call
site (mount path only)
- **Red flags**: None

**Record**: Minimal 2-line removal + comment. Obviously safe because
called only from mount path.

---

## PHASE 3: GIT HISTORY INVESTIGATION

### Step 3.1: Blame
- Buggy code (mutex_lock/unlock in
`btrfs_get_dev_zone_info_all_devices`) introduced by commit
`7365104236ade0` (Naohiro Aota, 2021-02-04)
- First appeared in **v5.12-rc1**
- Present in all current stable trees (v5.15.y, v6.1.y, v6.6.y, v6.12.y)

### Step 3.2: Fixes tag
No Fixes: tag present. The implicit target is `7365104236ade0` which
introduced the function with the mutex.

### Step 3.3: File History
- The lock dependency chain also depends on `2eadb9e75e8e65` (Nikolay
Borisov, 2021-07-05) which added `device_list_mutex` to
`btrfs_create_pending_block_groups` — first in **v5.15-rc1**
- So the deadlock is possible from **v5.15** onwards (when both sides of
the circular dependency exist)
- Prior lockdep fixes in this file: `0b9e66762aa0c` (device_list_mutex
deadlock in `btrfs_can_activate_zone`), `b18f3b60b35a8` (lock ordering
in `btrfs_zone_activate`)

### Step 3.4: Author
Johannes Thumshirn is a regular btrfs/zoned contributor and co-
maintainer of zoned storage code. High trust.

### Step 3.5: Dependencies
- The fix is completely self-contained: removes 2 lines, adds a comment
- No dependency on other commits
- The function and its surrounding code are unchanged since introduction
(except the `populate_cache` parameter added in v5.16)
- Will apply cleanly to all stable trees v5.15+

**Record**: Bug exists from v5.15+. Fix is standalone. Will apply
cleanly.

---

## PHASE 4: MAILING LIST RESEARCH

### Step 4.1: Lore Discussion
Found the original patch posted 2026-03-03. Reviewed by Damien Le Moal
(block/zoned expert) and David Sterba (btrfs maintainer). Included in
"Btrfs fixes for 7.0-rc5" pull request by David Sterba, confirming it's
treated as a fix.

### Step 4.2: Bug Report
The bug was found by Shin'ichiro Kawasaki in their CI system running
generic/013 (an fstests test). The lockdep splat is the primary
evidence. The commit also mentions "sporadic hangs."

### Step 4.3: Related Patches
No other patches in a series — this is a standalone fix.

### Step 4.4: Stable Discussion
No explicit stable nomination found, which is why this commit is being
manually reviewed.

**Record**: Standalone fix. Reviewed by 2 experts. Accepted as bugfix
for rc5.

---

## PHASE 5: CODE SEMANTIC ANALYSIS

### Step 5.1: Key Functions
- Modified: `btrfs_get_dev_zone_info_all_devices()`

### Step 5.2: Callers
- Single caller: `open_ctree()` in `fs/btrfs/disk-io.c:3464`
- This is the mount path — called during every btrfs mount operation on
zoned devices

### Step 5.3: Callees
- Calls `btrfs_get_dev_zone_info()` which calls `btrfs_get_dev_zones()`
which calls `blkdev_report_zones_cached()` (or `blkdev_report_zones()`
in older kernels) → block device driver zone report callback
- The block device callback (e.g., `virtblk_report_zones`) may take its
own mutex, creating the circular dependency

### Step 5.4: Call Chain
`mount` syscall → `vfs_get_tree` → `btrfs_get_tree` → `open_ctree` →
`btrfs_get_dev_zone_info_all_devices`
This is reachable from userspace during every mount of a zoned btrfs
filesystem.

### Step 5.5: Similar Patterns
Previous similar fix: `0b9e66762aa0c` removed `device_list_mutex` from
`btrfs_can_activate_zone()` for the same type of deadlock reason. This
pattern of removing unnecessary `device_list_mutex` usage has precedent.

**Record**: Called on every zoned btrfs mount. Single call site. Same
pattern as previous accepted fix.

---

## PHASE 6: STABLE TREE ANALYSIS

### Step 6.1: Buggy Code in Stable Trees
- The function `btrfs_get_dev_zone_info_all_devices` with
`device_list_mutex` exists since v5.12
- The other side of the circular dependency (`device_list_mutex` in
`btrfs_create_pending_block_groups`) exists since v5.15
- **Deadlock is possible in all stable trees from v5.15 onwards**:
v5.15.y, v6.1.y, v6.6.y, v6.12.y

### Step 6.2: Backport Complications
- The function is essentially unchanged since introduction (only
`populate_cache` parameter change in v5.16)
- The patch should apply cleanly to all stable trees v5.15+
- In v5.12-v5.14 the other side of the dependency doesn't exist, so the
deadlock can't occur there

### Step 6.3: Related Fixes in Stable
No fix for this specific deadlock is already in stable trees.

**Record**: Bug exists in v5.15+. Clean apply expected. No existing fix
in stable.

---

## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT

### Step 7.1: Subsystem
- **Subsystem**: btrfs (filesystem), zoned device support
- **Criticality**: IMPORTANT — btrfs is widely used, zoned storage is
growing (SMR HDDs, ZNS SSDs)

### Step 7.2: Activity
The btrfs zoned code is very actively developed with frequent fixes,
indicating ongoing maturation of this subsystem.

**Record**: btrfs/zoned — IMPORTANT criticality, actively developed.

---

## PHASE 8: IMPACT AND RISK ASSESSMENT

### Step 8.1: Affected Users
- All users of btrfs on zoned block devices (ZNS SSDs, SMR HDDs)
- Also affects users of btrfs zone emulation mode on regular devices
- Growing user population as zoned storage adoption increases

### Step 8.2: Trigger Conditions
- **Trigger**: Mount a zoned btrfs filesystem while another thread/CPU
holds locks in the transaction/mmap path (the lock ordering violation
makes this possible whenever two threads are active)
- **Frequency**: Sporadic — depends on timing, but confirmed
reproducible with fstests generic/013
- **Unprivileged trigger**: No — requires mount privileges

### Step 8.3: Failure Mode Severity
- **Failure mode**: System hang / deadlock during mount
- **Severity**: **CRITICAL** — deadlock makes the system unusable, mount
never completes
- Lockdep confirmed the circular dependency chain

### Step 8.4: Risk-Benefit Ratio
- **BENEFIT**: Very high — prevents deadlock/hang during mount of zoned
btrfs
- **RISK**: Very low — 2-line removal of an unnecessary lock in the
mount path, which is inherently single-threaded at that point
- The safety argument is sound: during `open_ctree()`, the filesystem is
being set up; no device add/remove operations can be happening
- **Ratio**: Excellent — minimal risk, high benefit

---

## PHASE 9: FINAL SYNTHESIS

### Step 9.1: Evidence Summary

**FOR backporting:**
- Fixes a real deadlock (sporadic hangs, confirmed by lockdep)
- Reported by a real tester (Shin'ichiro Kawasaki)
- Reviewed by block/zoned expert (Damien Le Moal) and btrfs maintainer
(David Sterba)
- Author is a trusted btrfs/zoned contributor (Johannes Thumshirn)
- Included in "Btrfs fixes for 7.0-rc5" — treated as a bugfix
- Surgical fix: 2 lines removed, comment added
- Bug exists in all stable trees v5.15+
- Will apply cleanly
- No dependencies
- Previous precedent for same pattern fix (`0b9e66762aa0c`)

**AGAINST backporting:**
- (None identified)

### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — the mount path is single-
threaded; no concurrent device list modification is possible. Tested
in CI.
2. **Fixes a real bug?** YES — deadlock during mount, confirmed by
lockdep
3. **Important issue?** YES — deadlock/hang, severity CRITICAL
4. **Small and contained?** YES — 2-line removal in 1 function, 1 file
5. **No new features or APIs?** YES — purely removes unnecessary locking
6. **Can apply to stable trees?** YES — clean apply expected for v5.15+

### Step 9.3: Exception Categories
Not applicable — this is a straightforward deadlock fix.

### Step 9.4: Decision
This is a clear YES. It fixes a real deadlock that causes system hangs
during mount of zoned btrfs filesystems. The fix is minimal, obviously
correct, well-reviewed, and will apply cleanly to stable trees.

---

## Verification

- **[Phase 1]** Parsed tags: Reported-by Shin'ichiro Kawasaki, Reviewed-
by Damien Le Moal and David Sterba, SOB Johannes Thumshirn and David
Sterba
- **[Phase 2]** Diff analysis: 2 lines removed (mutex_lock/unlock), 4
lines added (comment). Single function
`btrfs_get_dev_zone_info_all_devices()` in single file
`fs/btrfs/zoned.c`
- **[Phase 3]** git blame: buggy mutex_lock introduced in commit
`7365104236ade0` (v5.12-rc1, 2021-02-04). Other side of deadlock chain
in `2eadb9e75e8e65` (v5.15-rc1)
- **[Phase 3]** git describe: confirmed `7365104236ade0` first in
v5.12-rc1, `2eadb9e75e8e65` first in v5.15-rc1
- **[Phase 3]** Author history: Johannes Thumshirn is a regular
btrfs/zoned contributor with multiple commits to this file
- **[Phase 3]** Related fixes: `0b9e66762aa0c` used same pattern
(removing device_list_mutex) to fix deadlock in
`btrfs_can_activate_zone`
- **[Phase 4]** lore.kernel.org: Patch found posted 2026-03-03, reviewed
by Damien Le Moal and David Sterba, included in "Btrfs fixes for
7.0-rc5"
- **[Phase 5]** Single caller: `open_ctree()` at `disk-io.c:3464` —
mount path only
- **[Phase 5]** Call chain traced: mount syscall → vfs_get_tree →
btrfs_get_tree → open_ctree → btrfs_get_dev_zone_info_all_devices
- **[Phase 6]** Stable tree check: confirmed zoned.c has been modified
in v5.15.y, v6.1.y, v6.6.y stable trees (function present in all)
- **[Phase 6]** No conflicting fixes found in stable for this specific
issue
- **[Phase 7]** Subsystem: btrfs (IMPORTANT criticality), actively
developed
- **[Phase 8]** Failure mode: deadlock/hang during mount — CRITICAL
severity
- **[Phase 8]** Risk: Very low (2-line lock removal in single-threaded
mount path)
- UNVERIFIED: Exact clean apply status for each individual stable branch
(would need cherry-pick test), but function code is nearly identical
across all stable trees

**YES**

fs/btrfs/zoned.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/zoned.c b/fs/btrfs/zoned.c
index 392e6ad874cc7..ab7cc30212702 100644
--- a/fs/btrfs/zoned.c
+++ b/fs/btrfs/zoned.c
@@ -337,7 +337,10 @@ int btrfs_get_dev_zone_info_all_devices(struct btrfs_fs_info *fs_info)
if (!btrfs_fs_incompat(fs_info, ZONED))
return 0;

- mutex_lock(&fs_devices->device_list_mutex);
+ /*
+ * No need to take the device_list mutex here, we're still in the mount
+ * path and devices cannot be added to or removed from the list yet.
+ */
list_for_each_entry(device, &fs_devices->devices, dev_list) {
/* We can skip reading of zone info for missing devices */
if (!device->bdev)
@@ -347,7 +350,6 @@ int btrfs_get_dev_zone_info_all_devices(struct btrfs_fs_info *fs_info)
if (ret)
break;
}
- mutex_unlock(&fs_devices->device_list_mutex);

return ret;
}
--
2.51.0