On Wed, Jan 30, 2019 at 02:45:00PM +0800, Anand Jain wrote: > v3->v4: Fix list corruption as reported by btrfs/073 by David. > [1] > https://patchwork.kernel.org/patch/10705741/ > Which I was able to reproduce with an instrumented kernel but not with > btrfs/073. > In v3 patch, it releases the fs_info::scrub_lock to destroy the work queue > which raced with new scrub requests, overwriting the scrub workers > pointers. So in v4, it kills the function scrub_workers_put(), and > performs the destroy_workqueue in two stages, with worker pointers > copied locally. > @@ -3932,9 +3925,16 @@ int btrfs_scrub_dev(struct btrfs_fs_info *fs_info, u64 devid, u64 start, > > mutex_lock(&fs_info->scrub_lock); > dev->scrub_ctx = NULL; > - scrub_workers_put(fs_info); > + if (--fs_info->scrub_workers_refcnt == 0) { > + scrub_workers = fs_info->scrub_workers; > + scrub_wr_comp = fs_info->scrub_wr_completion_workers; > + scrub_parity = fs_info->scrub_parity_workers; > + } > mutex_unlock(&fs_info->scrub_lock); > > + btrfs_destroy_workqueue(scrub_workers); > + btrfs_destroy_workqueue(scrub_wr_comp); > + btrfs_destroy_workqueue(scrub_parity); https://lore.kernel.org/linux-btrfs/1543554924-17397-2-git-send-email-anand.jain@xxxxxxxxxx/ Comparing to the previous version, it's almost the same I think. If scrub_workers_get races between the unlock and destroy_workers, anything that uses fs_info->scrub_wokers will soon use freed memory. The difference is that the worker pointers are read from fs_info under a lock but are still used outside. I haven't tested this version but from the analysis of previous crash, I don't see how v4 is supposed to be better.
