]> git.baikalelectronics.ru Git - kernel.git/commit
btrfs: hold block group refcount during async discard
authorBoris Burkov <boris@bur.io>
Fri, 13 Jan 2023 00:05:11 +0000 (16:05 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 10 Mar 2023 08:34:06 +0000 (09:34 +0100)
commit811ae7ebeb0b00710947c24d41e9ba1116b9a53a
treeabc775d7c382f806f31b71afbe557f97d9e764b6
parent062e3e34f01decdb0b8cd127879f177816ea9b3a
btrfs: hold block group refcount during async discard

commit b4872b30b8d7b8fd00a80e653068e3d9dc83705d upstream.

Async discard does not acquire the block group reference count while it
holds a reference on the discard list. This is generally OK, as the
paths which destroy block groups tend to try to synchronize on
cancelling async discard work. However, relying on cancelling work
requires careful analysis to be sure it is safe from races with
unpinning scheduling more work.

While I am unable to find a race with unpinning in the current code for
either the unused bgs or relocation paths, I believe we have one in an
older version of auto relocation in a Meta internal build. This suggests
that this is in fact an error prone model, and could be fragile to
future changes to these bg deletion paths.

To make this ownership more clear, add a refcount for async discard. If
work is queued for a block group, its refcount should be incremented,
and when work is completed or canceled, it should be decremented.

CC: stable@vger.kernel.org # 5.15+
Signed-off-by: Boris Burkov <boris@bur.io>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/btrfs/discard.c