On Fri, Feb 14, 2020 at 03:33:23PM -0500, Qian Cai wrote: > struct vm_area_struct could be accessed concurrently as noticed by > KCSAN, > > write to 0xffff9cf8bba08ad8 of 8 bytes by task 14263 on cpu 35: > vma_interval_tree_insert+0x101/0x150: > rb_insert_augmented_cached at include/linux/rbtree_augmented.h:58 > (inlined by) vma_interval_tree_insert at mm/interval_tree.c:23 > __vma_link_file+0x6e/0xe0 > __vma_link_file at mm/mmap.c:629 > vma_link+0xa2/0x120 > mmap_region+0x753/0xb90 > do_mmap+0x45c/0x710 > vm_mmap_pgoff+0xc0/0x130 > ksys_mmap_pgoff+0x1d1/0x300 > __x64_sys_mmap+0x33/0x40 > do_syscall_64+0x91/0xc44 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > read to 0xffff9cf8bba08a80 of 200 bytes by task 14262 on cpu 122: > vm_area_dup+0x6a/0xe0 > vm_area_dup at kernel/fork.c:362 > __split_vma+0x72/0x2a0 > __split_vma at mm/mmap.c:2661 > split_vma+0x5a/0x80 > mprotect_fixup+0x368/0x3f0 > do_mprotect_pkey+0x263/0x420 > __x64_sys_mprotect+0x51/0x70 > do_syscall_64+0x91/0xc44 > entry_SYSCALL_64_after_hwframe+0x49/0xbe > > The write is holding mmap_sem while changing vm_area_struct.shared.rb. > Even though the read is lockless while making a copy, the clone will > have its own shared.rb reinitialized. Thus, mark it as an intentional > data race using the data_race() macro. I'm confused. AFAICS both sides hold mmap_sem on write: - vm_mmap_pgoff() takes mmap_sem for the write on the write side - do_mprotect_pkey() takes mmap_sem for the write on the read side What do I miss? -- Kirill A. Shutemov
