On Wed, Feb 19, 2020 at 09:28:15AM -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 > > vm_area_dup() blindly copies all fields of original VMA to the new one. > This includes coping vm_area_struct::shared.rb which is normally > protected by i_mmap_lock. But this is fine because the read value will > be overwritten on the following __vma_link_file() under proper > protection. Thus, mark it as an intentional data race and insert a few > assertions for the fields that should not be modified concurrently. > > Signed-off-by: Qian Cai <cai@xxxxxx> Acked-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> -- Kirill A. Shutemov
