diff options
author | Naohiro Aota <naohiro.aota@wdc.com> | 2023-12-22 13:56:34 +0900 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2024-01-12 02:00:09 +0100 |
commit | b18f3b60b35a8c01c9a2a0f0d6424c6d73971dc3 (patch) | |
tree | 2b0cc5676fd2cef0d53aa490165a76168ca111f7 /arch/arm | |
parent | d967c914a633ee797255261808720f791b658f24 (diff) | |
download | linux-stable-b18f3b60b35a8c01c9a2a0f0d6424c6d73971dc3.tar.gz linux-stable-b18f3b60b35a8c01c9a2a0f0d6424c6d73971dc3.tar.bz2 linux-stable-b18f3b60b35a8c01c9a2a0f0d6424c6d73971dc3.zip |
btrfs: zoned: fix lock ordering in btrfs_zone_activate()
The btrfs CI reported a lockdep warning as follows by running generic
generic/129.
WARNING: possible circular locking dependency detected
6.7.0-rc5+ #1 Not tainted
------------------------------------------------------
kworker/u5:5/793427 is trying to acquire lock:
ffff88813256d028 (&cache->lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x5e/0x130
but task is already holding lock:
ffff88810a23a318 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}, at: btrfs_zone_finish_one_bg+0x34/0x130
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #1 (&fs_info->zone_active_bgs_lock){+.+.}-{2:2}:
...
-> #0 (&cache->lock){+.+.}-{2:2}:
...
This is because we take fs_info->zone_active_bgs_lock after a block_group's
lock in btrfs_zone_activate() while doing the opposite in other places.
Fix the issue by expanding the fs_info->zone_active_bgs_lock's critical
section and taking it before a block_group's lock.
Fixes: a7e1ac7bdc5a ("btrfs: zoned: reserve zones for an active metadata/system block group")
CC: stable@vger.kernel.org # 6.6
Signed-off-by: Naohiro Aota <naohiro.aota@wdc.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'arch/arm')
0 files changed, 0 insertions, 0 deletions