Possible data race on btrfs_set_block_group_used(&cache->item, ...) when two syncfs runs in parallel

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

 



Hi Btrfs Developer,

I am writing to report a data race between
btrfs_set_block_group_used(&cache->item, ...) and memcpy() while both
threads are running syncfs. Following is the call stack observed at
run time. I can confirm that the order of the [READ] and [WRITE]
statements are not deterministic.

[Setup]
create("bar", 511) = 3;
dup2(3, 198) = 198;
open("baz", 2097152, 511) = 4;


[Thread 1]
syncfs(4);

__do_sys_syncfs
  sync_filesystem
    __sync_filesystem
      btrfs_sync_fs
        btrfs_commit_transaction
          btrfs_start_dirty_block_groups
            write_one_cache_group
              write_extent_buffer
                [READ] memcpy(kaddr + offset, src, cur)  (src is the
pointer read)


[Thread 2]
syncfs(198);

__do_sys_syncfs
  sync_filesystem
    __sync_filesystem
      btrfs_sync_fs
        btrfs_commit_transaction
          btrfs_run_delayed_refs
            __btrfs_run_delayed_refs
               btrfs_run_delayed_refs_for_head
                 run_one_delayed_ref
                   run_delayed_tree_ref
                     alloc_reserved_tree_block
                       btrfs_update_block_group
                         btrfs_set_block_group_used
                           [WRITE]
btrfs_set_block_group_used(&cache->item, old_val);

Would you mind confirming whether this is a valid data race and
whether this might lead to inconsistent states on disk?

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