potential data race on `delayed_rsv->full`

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Btrfs maintainers,

I am reporting a potential data race around the `delayed_rsv->full` field.

[thread 1] mount a btrfs image, a kernel thread of uuid_rescan will be created

btrfs_uuid_rescan_kthread
  btrfs_end_transaction
    __btrfs_end_transaction
      btrfs_trans_release_metadata
        btrfs_block_rsv_release
          __btrfs_block_rsv_release
            --> [READ] else if (block_rsv != global_rsv && !delayed_rsv->full)
                                                            ^^^^^^^^^^^^^^^^^


[thread 2] do a mkdir syscall on the mounted image

__do_sys_mkdir
  do_mkdirat
    vfs_mkdir
      btrfs_mkdir
        btrfs_new_inode
          btrfs_insert_empty_items
            btrfs_cow_block
              __btrfs_cow_block
                alloc_tree_block_no_bg_flush
                  btrfs_alloc_tree_block
                    btrfs_add_delayed_tree_ref
                      btrfs_update_delayed_refs_rsv
                        --> [WRITE] delayed_rsv->full = 0;
                                    ^^^^^^^^^^^^^^^^^^^^^


I could confirm that this is a data race by manually adding and adjusting
delays before the read and write statements although I am not very sure
about the implication of such a data race (e.g., crashing btrfs or causing
violations of assumptions). I would appreciate if you could help check on
this potential bug and advise whether this is a harmful data race or it
is intended.

Best Regards,
Meng



[Index of Archives]     [Linux Filesystem Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux