On 2020/5/9 18:53, Nikolay Borisov wrote:
On 9.05.20 г. 8:20 ч., Jia-Ju Bai wrote:
The functions btrfs_block_group_done() and caching_thread() are
concurrently executed at runtime in the following call contexts:
Thread 1:
btrfs_sync_file()
start_ordered_ops()
btrfs_fdatawrite
On 9.05.20 г. 8:20 ч., Jia-Ju Bai wrote:
> The functions btrfs_block_group_done() and caching_thread() are
> concurrently executed at runtime in the following call contexts:
>
> Thread 1:
> btrfs_sync_file()
> start_ordered_ops()
> btrfs_fdatawrite_range()
> btrfs_writepage
> This data race was found and actually reproduced by our concurrency fuzzer.
I have got the impression that this patch series has got a questionable
mail threading.
Will it be helpful to resend it with a cover letter together with a few
adjustments for the corresponding change descriptions?
https
> To fix this race, the spinlock cache->lock is used to protect the
> access to cache->cached in btrfs_block_group_done().
How do you think about to replace this wording by a variant like the following?
Thus use the spin lock “cache->lock” to protect the access to
the data structure member
The functions btrfs_block_group_done() and caching_thread() are
concurrently executed at runtime in the following call contexts:
Thread 1:
btrfs_sync_file()
start_ordered_ops()
btrfs_fdatawrite_range()
btrfs_writepages() [via function pointer]
extent_writepages()
5 matches
Mail list logo
