On 2020/5/13 6:18, David Sterba wrote:
On Sat, May 09, 2020 at 01:34:31PM +0800, Jia-Ju Bai wrote:The functions btrfs_block_rsv_release() and btrfs_update_delayed_refs_rsv() are concurrently executed at runtime in the following call contexts: Thread 1: btrfs_file_write_iter() btrfs_buffered_write() btrfs_delalloc_release_extents() btrfs_inode_rsv_release() __btrfs_block_rsv_release() Thread 2: finish_ordered_fn() btrfs_finish_ordered_io() insert_reserved_file_extent() __btrfs_drop_extents() btrfs_free_extent() btrfs_add_delayed_data_ref() btrfs_update_delayed_refs_rsv() In __btrfs_block_rsv_release(): else if (... && !delayed_rsv->full) In btrfs_update_delayed_refs_rsv(): spin_lock(&delayed_rsv->lock); delayed_rsv->size += num_bytes; delayed_rsv->full = 0; spin_unlock(&delayed_rsv->lock); Thus a data race for delayed_rsv->full can occur. This race was found and actually reproduced by our conccurency fuzzer. To fix this race, the spinlock delayed_rsv->lock is used to protect the access to delayed_rsv->full in btrfs_block_rsv_release(). Signed-off-by: Jia-Ju Bai <baijiaju1...@gmail.com> --- fs/btrfs/block-rsv.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/block-rsv.c b/fs/btrfs/block-rsv.c index 27efec8f7c5b..89c53a7137b4 100644 --- a/fs/btrfs/block-rsv.c +++ b/fs/btrfs/block-rsv.c @@ -277,6 +277,11 @@ u64 btrfs_block_rsv_release(struct btrfs_fs_info *fs_info, struct btrfs_block_rsv *global_rsv = &fs_info->global_block_rsv; struct btrfs_block_rsv *delayed_rsv = &fs_info->delayed_refs_rsv; struct btrfs_block_rsv *target = NULL; + unsigned short full = 0; + + spin_lock(&delayed_rsv->lock); + full = delayed_rsv->full; + spin_unlock(&delayed_rsv->lock);/** If we are the delayed_rsv then push to the global rsv, otherwise dump @@ -284,7 +289,7 @@ u64 btrfs_block_rsv_release(struct btrfs_fs_info *fs_info, */ if (block_rsv == delayed_rsv) target = global_rsv; - else if (block_rsv != global_rsv && !delayed_rsv->full) + else if (block_rsv != global_rsv && !full)This has been reported as suspicous https://lore.kernel.org/linux-btrfs/CAAwBoOJDjei5Hnem155N_cJwiEkVwJYvgN-tQrwWbZQGhFU=c...@mail.gmail.com/ and there's an answer that this is racy but does not cause any unexpected behaviour.
Okay, thanks :) Best wishes, Jia-Ju Bai
