diff options
| author | Omar Sandoval <[email protected]> | 2019-09-16 18:30:55 +0000 |
|---|---|---|
| committer | David Sterba <[email protected]> | 2019-11-18 11:46:48 +0000 |
| commit | e732fe95e4cad35fc1df278c23a32903341b08b3 (patch) | |
| tree | ce00fb9dc70673edb62aca1e5aabe0c90ae7fea7 /fs/btrfs/async-thread.h | |
| parent | btrfs: don't prematurely free work in end_workqueue_fn() (diff) | |
| download | kernel-e732fe95e4cad35fc1df278c23a32903341b08b3.tar.gz kernel-e732fe95e4cad35fc1df278c23a32903341b08b3.zip | |
btrfs: don't prematurely free work in reada_start_machine_worker()
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 <[email protected]>
Signed-off-by: Omar Sandoval <[email protected]>
Reviewed-by: David Sterba <[email protected]>
Signed-off-by: David Sterba <[email protected]>
Diffstat (limited to 'fs/btrfs/async-thread.h')
0 files changed, 0 insertions, 0 deletions
