Re: KCSAN: data-race in __rb_rotate_set_parents / vm_area_dup

[Marco Elver]

On Thu, 24 Oct 2019 at 18:25, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
> >
> > ==================================================================
> > 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.

> How do you tell it to shut up?

We wanted to get feedback on what is happening here, as it didn't seem
straightforward to dismiss on our side.

Is it correct to assume that, the parts of the *orig struct that are
being modified while being copied, will subsequently be re-initialized
for *new?

If no explicit markings are useful (READ_ONCE would suppress it, but
seems strange if the above assumption is true), I will think of a way
to suppress these for now and no further action is needed here.

Many thanks,
-- Marco