summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/task-analyzer.py
diff options
context:
space:
mode:
authorBoris Burkov <boris@bur.io>2025-03-04 02:01:05 +0300
committerDavid Sterba <dsterba@suse.com>2025-03-18 22:35:51 +0300
commit895c6721d310c036dcfebb5ab845822229fa35eb (patch)
tree5f588529c3a6f02149bb3e8823381d9c66286fe7 /tools/perf/scripts/python/task-analyzer.py
parent7511e29cf1355b2c47d0effb39e463119913e2f6 (diff)
downloadlinux-895c6721d310c036dcfebb5ab845822229fa35eb.tar.xz
btrfs: make btrfs_discard_workfn() block_group ref explicit
Currently, the async discard machinery owns a ref to the block_group when the block_group is queued on a discard list. However, to handle races with discard cancellation and the discard workfn, we have a specific logic to detect that the block_group is *currently* running in the workfn, to protect the workfn's usage amidst cancellation. As far as I can tell, this doesn't have any overt bugs (though finish_discard_pass() and remove_from_discard_list() racing can have a surprising outcome for the caller of remove_from_discard_list() in that it is again added at the end). But it is needlessly complicated to rely on locking and the nullity of discard_ctl->block_group. Simplify this significantly by just taking a refcount while we are in the workfn and unconditionally drop it in both the remove and workfn paths, regardless of if they race. Reviewed-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Boris Burkov <boris@bur.io> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/task-analyzer.py')
0 files changed, 0 insertions, 0 deletions