]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
btrfs: don't prematurely free work in reada_start_machine_worker()
authorOmar Sandoval <osandov@fb.com>
Mon, 16 Sep 2019 18:30:55 +0000 (11:30 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 4 Jan 2020 12:40:09 +0000 (13:40 +0100)
commitc3c7c0cc4838ddaa91b95a2705cb8811dafe066f
tree377bb0f3776c3e26f3483e5b632f799f01e39ef9
parent5baa2f382b4ac6de7953d49170aca4ab1e412d97
btrfs: don't prematurely free work in reada_start_machine_worker()

[ Upstream commit e732fe95e4cad35fc1df278c23a32903341b08b3 ]

Currently, reada_start_machine_worker() frees the reada_machine_work and
then calls __reada_start_machine() to do readahead. This is another
potential instance of the bug in "btrfs: don't prematurely free work in
run_ordered_work()".

There _might_ already be a deadlock here: reada_start_machine_worker()
can depend on itself through stacked filesystems (__read_start_machine()
-> reada_start_machine_dev() -> reada_tree_block_flagged() ->
read_extent_buffer_pages() -> submit_one_bio() ->
btree_submit_bio_hook() -> btrfs_map_bio() -> submit_stripe_bio() ->
submit_bio() onto a loop device can trigger readahead on the lower
filesystem).

Either way, let's fix it by freeing the work at the end.

Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
fs/btrfs/reada.c