[PATCH 4/4] fs: btrfs: fix a data race in btrfs_block_rsv_release()

[PATCH 4/4] fs: btrfs: fix a data race in btrfs_block_rsv_release()

[Jia-Ju Bai]

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 <baijiaju1990@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)
 		target = delayed_rsv;
 
 	if (target && block_rsv->space_info != target->space_info)
-- 
2.17.1

Re: [PATCH 4/4] fs: btrfs: fix a data race in btrfs_block_rsv_release()

[David Sterba]

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 <baijiaju1990@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=cA@mail.gmail.com/

and there's an answer that this is racy but does not cause any
unexpected behaviour.

Re: [PATCH 4/4] fs: btrfs: fix a data race in btrfs_block_rsv_release()

[Jia-Ju Bai]

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 <baijiaju1990@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=cA@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