Messages in this thread | | | Date | Fri, 25 Oct 2019 11:01:13 +0200 | From | Peter Zijlstra <> | Subject | Re: KCSAN: data-race in __rb_rotate_set_parents / vm_area_dup |
| |
On Thu, Oct 24, 2019 at 08:59:50PM +0200, Marco Elver wrote: > On Thu, 24 Oct 2019 at 18:25, Peter Zijlstra <peterz@infradead.org> wrote: > > > > On Thu, Oct 24, 2019 at 09:07:08AM -0700, syzbot wrote: > > > Hello, > > > > > > syzbot found the following crash on: > > > > > > HEAD commit: 05f22368 x86, kcsan: Enable KCSAN for x86 > > > git tree: https://github.com/google/ktsan.git kcsan > > > console output: https://syzkaller.appspot.com/x/log.txt?x=1060c47b600000 > > > kernel config: https://syzkaller.appspot.com/x/.config?x=87d111955f40591f > > > dashboard link: https://syzkaller.appspot.com/bug?extid=c034966b0b02f94f7f34 > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental) > > > > > > Unfortunately, I don't have any reproducer for this crash yet. > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit: > > > Reported-by: syzbot+c034966b0b02f94f7f34@syzkaller.appspotmail.com > > > > > > ================================================================== > > > BUG: KCSAN: data-race in __rb_rotate_set_parents / vm_area_dup > > > > > > read to 0xffff88811eef53e8 of 200 bytes by task 7738 on cpu 0: > > > vm_area_dup+0x70/0xf0 kernel/fork.c:359 > > > __split_vma+0x88/0x350 mm/mmap.c:2678 > > > __do_munmap+0xb02/0xb60 mm/mmap.c:2803 > > > do_munmap mm/mmap.c:2856 [inline] > > > mmap_region+0x165/0xd50 mm/mmap.c:1749 > > > do_mmap+0x6d4/0xba0 mm/mmap.c:1577 > > > do_mmap_pgoff include/linux/mm.h:2353 [inline] > > > vm_mmap_pgoff+0x12d/0x190 mm/util.c:496 > > > ksys_mmap_pgoff+0x2d8/0x420 mm/mmap.c:1629 > > > __do_sys_mmap arch/x86/kernel/sys_x86_64.c:100 [inline] > > > __se_sys_mmap arch/x86/kernel/sys_x86_64.c:91 [inline] > > > __x64_sys_mmap+0x91/0xc0 arch/x86/kernel/sys_x86_64.c:91 > > > do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > > > write to 0xffff88811eef5440 of 8 bytes by task 7737 on cpu 1: > > > __rb_rotate_set_parents+0x4d/0xf0 lib/rbtree.c:79 > > > __rb_insert lib/rbtree.c:215 [inline] > > > __rb_insert_augmented+0x109/0x370 lib/rbtree.c:459 > > > rb_insert_augmented include/linux/rbtree_augmented.h:50 [inline] > > > rb_insert_augmented_cached include/linux/rbtree_augmented.h:60 [inline] > > > vma_interval_tree_insert+0x196/0x230 mm/interval_tree.c:23 > > > __vma_link_file+0xd9/0x110 mm/mmap.c:634 > > > __vma_adjust+0x1ac/0x12a0 mm/mmap.c:842 > > > vma_adjust include/linux/mm.h:2276 [inline] > > > __split_vma+0x208/0x350 mm/mmap.c:2707 > > > split_vma+0x73/0xa0 mm/mmap.c:2736 > > > mprotect_fixup+0x43f/0x510 mm/mprotect.c:413 > > > do_mprotect_pkey+0x3eb/0x660 mm/mprotect.c:553 > > > __do_sys_mprotect mm/mprotect.c:578 [inline] > > > __se_sys_mprotect mm/mprotect.c:575 [inline] > > > __x64_sys_mprotect+0x51/0x70 mm/mprotect.c:575 > > > do_syscall_64+0xcc/0x370 arch/x86/entry/common.c:290 > > > entry_SYSCALL_64_after_hwframe+0x44/0xa9 > > > > What is this thing trying to tell me? That the copy on alloc is racy, > > because at that point the object isn't exposed yet. > > In vm_area_dup, *orig is being concurrently modified while being > copied into *new.
I'm not sure how it thinks there is concurrency here though; __split_vma() *should* be holding mmap_sem for writing.
But yes, at least all the rb-tree and list crud should be re-initialized for the object after copy.
| |