2021-11-18 14:20:29

by syzbot

[permalink] [raw]
Subject: [syzbot] KCSAN: data-race in flush_tlb_batched_pending / try_to_unmap_one

Hello,

syzbot found the following issue on:

HEAD commit: 42eb8fdac2fc Merge tag 'gfs2-v5.16-rc2-fixes' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13160026b00000
kernel config: https://syzkaller.appspot.com/x/.config?x=a70237460d215073
dashboard link: https://syzkaller.appspot.com/bug?extid=aa5bebed695edaccf0df
compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2

Unfortunately, I don't have any reproducer for this issue yet.

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: [email protected]

==================================================================
BUG: KCSAN: data-race in flush_tlb_batched_pending / try_to_unmap_one

write to 0xffff8881072cfbbc of 1 bytes by task 17406 on cpu 1:
flush_tlb_batched_pending+0x5f/0x80 mm/rmap.c:691
madvise_free_pte_range+0xee/0x7d0 mm/madvise.c:594
walk_pmd_range mm/pagewalk.c:128 [inline]
walk_pud_range mm/pagewalk.c:205 [inline]
walk_p4d_range mm/pagewalk.c:240 [inline]
walk_pgd_range mm/pagewalk.c:277 [inline]
__walk_page_range+0x981/0x1160 mm/pagewalk.c:379
walk_page_range+0x131/0x300 mm/pagewalk.c:475
madvise_free_single_vma mm/madvise.c:734 [inline]
madvise_dontneed_free mm/madvise.c:822 [inline]
madvise_vma mm/madvise.c:996 [inline]
do_madvise+0xe4a/0x1140 mm/madvise.c:1202
__do_sys_madvise mm/madvise.c:1228 [inline]
__se_sys_madvise mm/madvise.c:1226 [inline]
__x64_sys_madvise+0x5d/0x70 mm/madvise.c:1226
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae

write to 0xffff8881072cfbbc of 1 bytes by task 71 on cpu 0:
set_tlb_ubc_flush_pending mm/rmap.c:636 [inline]
try_to_unmap_one+0x60e/0x1220 mm/rmap.c:1515
rmap_walk_anon+0x2fb/0x470 mm/rmap.c:2301
try_to_unmap+0xec/0x110
shrink_page_list+0xe91/0x2620 mm/vmscan.c:1719
shrink_inactive_list+0x3fb/0x730 mm/vmscan.c:2394
shrink_list mm/vmscan.c:2621 [inline]
shrink_lruvec+0x3c9/0x710 mm/vmscan.c:2940
shrink_node_memcgs+0x23e/0x410 mm/vmscan.c:3129
shrink_node+0x8f6/0x1190 mm/vmscan.c:3252
kswapd_shrink_node mm/vmscan.c:4022 [inline]
balance_pgdat+0x702/0xd30 mm/vmscan.c:4213
kswapd+0x200/0x340 mm/vmscan.c:4473
kthread+0x2c7/0x2e0 kernel/kthread.c:327
ret_from_fork+0x1f/0x30

value changed: 0x01 -> 0x00

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 71 Comm: kswapd0 Not tainted 5.16.0-rc1-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
==================================================================


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at [email protected].

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.


2021-11-18 14:49:17

by Marco Elver

[permalink] [raw]
Subject: Re: [syzbot] KCSAN: data-race in flush_tlb_batched_pending / try_to_unmap_one

On Thu, Nov 18, 2021 at 06:20AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 42eb8fdac2fc Merge tag 'gfs2-v5.16-rc2-fixes' of git://git..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13160026b00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=a70237460d215073
> dashboard link: https://syzkaller.appspot.com/bug?extid=aa5bebed695edaccf0df
> compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: [email protected]
>
> ==================================================================
> BUG: KCSAN: data-race in flush_tlb_batched_pending / try_to_unmap_one
>
> write to 0xffff8881072cfbbc of 1 bytes by task 17406 on cpu 1:
> flush_tlb_batched_pending+0x5f/0x80 mm/rmap.c:691
> madvise_free_pte_range+0xee/0x7d0 mm/madvise.c:594
> walk_pmd_range mm/pagewalk.c:128 [inline]
> walk_pud_range mm/pagewalk.c:205 [inline]
> walk_p4d_range mm/pagewalk.c:240 [inline]
> walk_pgd_range mm/pagewalk.c:277 [inline]
> __walk_page_range+0x981/0x1160 mm/pagewalk.c:379
> walk_page_range+0x131/0x300 mm/pagewalk.c:475
> madvise_free_single_vma mm/madvise.c:734 [inline]
> madvise_dontneed_free mm/madvise.c:822 [inline]
> madvise_vma mm/madvise.c:996 [inline]
> do_madvise+0xe4a/0x1140 mm/madvise.c:1202
> __do_sys_madvise mm/madvise.c:1228 [inline]
> __se_sys_madvise mm/madvise.c:1226 [inline]
> __x64_sys_madvise+0x5d/0x70 mm/madvise.c:1226
> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
> entry_SYSCALL_64_after_hwframe+0x44/0xae
>
> write to 0xffff8881072cfbbc of 1 bytes by task 71 on cpu 0:
> set_tlb_ubc_flush_pending mm/rmap.c:636 [inline]
> try_to_unmap_one+0x60e/0x1220 mm/rmap.c:1515
> rmap_walk_anon+0x2fb/0x470 mm/rmap.c:2301
> try_to_unmap+0xec/0x110
> shrink_page_list+0xe91/0x2620 mm/vmscan.c:1719
> shrink_inactive_list+0x3fb/0x730 mm/vmscan.c:2394
> shrink_list mm/vmscan.c:2621 [inline]
> shrink_lruvec+0x3c9/0x710 mm/vmscan.c:2940
> shrink_node_memcgs+0x23e/0x410 mm/vmscan.c:3129
> shrink_node+0x8f6/0x1190 mm/vmscan.c:3252
> kswapd_shrink_node mm/vmscan.c:4022 [inline]
> balance_pgdat+0x702/0xd30 mm/vmscan.c:4213
> kswapd+0x200/0x340 mm/vmscan.c:4473
> kthread+0x2c7/0x2e0 kernel/kthread.c:327
> ret_from_fork+0x1f/0x30
>
> value changed: 0x01 -> 0x00
>
> Reported by Kernel Concurrency Sanitizer on:
> CPU: 0 PID: 71 Comm: kswapd0 Not tainted 5.16.0-rc1-syzkaller #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> ==================================================================

Reading 3ea277194daae, I can't quite determine if this is safe and
expected.

Per this observed write/write race, depending on interleaving
tlb_flush_batched can randomly be true or false after
set_tlb_ubc_flush_pending().

Is this safe?

Thanks,
-- Marco

2021-11-20 06:11:17

by Nadav Amit

[permalink] [raw]
Subject: Re: [syzbot] KCSAN: data-race in flush_tlb_batched_pending / try_to_unmap_one


> On Nov 18, 2021, at 6:49 AM, Marco Elver <[email protected]> wrote:
>
> On Thu, Nov 18, 2021 at 06:20AM -0800, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit: 42eb8fdac2fc Merge tag 'gfs2-v5.16-rc2-fixes' of git://git..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=13160026b00000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=a70237460d215073
>> dashboard link: https://syzkaller.appspot.com/bug?extid=aa5bebed695edaccf0df
>> compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
>>
>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: [email protected]
>>
>> ==================================================================
>> BUG: KCSAN: data-race in flush_tlb_batched_pending / try_to_unmap_one
>>
>> write to 0xffff8881072cfbbc of 1 bytes by task 17406 on cpu 1:
>> flush_tlb_batched_pending+0x5f/0x80 mm/rmap.c:691
>> madvise_free_pte_range+0xee/0x7d0 mm/madvise.c:594
>> walk_pmd_range mm/pagewalk.c:128 [inline]
>> walk_pud_range mm/pagewalk.c:205 [inline]
>> walk_p4d_range mm/pagewalk.c:240 [inline]
>> walk_pgd_range mm/pagewalk.c:277 [inline]
>> __walk_page_range+0x981/0x1160 mm/pagewalk.c:379
>> walk_page_range+0x131/0x300 mm/pagewalk.c:475
>> madvise_free_single_vma mm/madvise.c:734 [inline]
>> madvise_dontneed_free mm/madvise.c:822 [inline]
>> madvise_vma mm/madvise.c:996 [inline]
>> do_madvise+0xe4a/0x1140 mm/madvise.c:1202
>> __do_sys_madvise mm/madvise.c:1228 [inline]
>> __se_sys_madvise mm/madvise.c:1226 [inline]
>> __x64_sys_madvise+0x5d/0x70 mm/madvise.c:1226
>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
>> entry_SYSCALL_64_after_hwframe+0x44/0xae
>>
>> write to 0xffff8881072cfbbc of 1 bytes by task 71 on cpu 0:
>> set_tlb_ubc_flush_pending mm/rmap.c:636 [inline]
>> try_to_unmap_one+0x60e/0x1220 mm/rmap.c:1515
>> rmap_walk_anon+0x2fb/0x470 mm/rmap.c:2301
>> try_to_unmap+0xec/0x110
>> shrink_page_list+0xe91/0x2620 mm/vmscan.c:1719
>> shrink_inactive_list+0x3fb/0x730 mm/vmscan.c:2394
>> shrink_list mm/vmscan.c:2621 [inline]
>> shrink_lruvec+0x3c9/0x710 mm/vmscan.c:2940
>> shrink_node_memcgs+0x23e/0x410 mm/vmscan.c:3129
>> shrink_node+0x8f6/0x1190 mm/vmscan.c:3252
>> kswapd_shrink_node mm/vmscan.c:4022 [inline]
>> balance_pgdat+0x702/0xd30 mm/vmscan.c:4213
>> kswapd+0x200/0x340 mm/vmscan.c:4473
>> kthread+0x2c7/0x2e0 kernel/kthread.c:327
>> ret_from_fork+0x1f/0x30
>>
>> value changed: 0x01 -> 0x00
>>
>> Reported by Kernel Concurrency Sanitizer on:
>> CPU: 0 PID: 71 Comm: kswapd0 Not tainted 5.16.0-rc1-syzkaller #0
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>> ==================================================================
>
> Reading 3ea277194daae, I can't quite determine if this is safe and
> expected.
>
> Per this observed write/write race, depending on interleaving
> tlb_flush_batched can randomly be true or false after
> set_tlb_ubc_flush_pending().
>
> Is this safe?
>

I do not think it is safe and I am not the only one.

https://lore.kernel.org/linux-mm/[email protected]/

Perhaps Huang has the cycles to fix it.

Regards,
Nadav

2021-11-22 06:46:14

by Huang, Ying

[permalink] [raw]
Subject: Re: [syzbot] KCSAN: data-race in flush_tlb_batched_pending / try_to_unmap_one

Nadav Amit <[email protected]> writes:

>> On Nov 18, 2021, at 6:49 AM, Marco Elver <[email protected]> wrote:
>>
>> On Thu, Nov 18, 2021 at 06:20AM -0800, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following issue on:
>>>
>>> HEAD commit: 42eb8fdac2fc Merge tag 'gfs2-v5.16-rc2-fixes' of git://git..
>>> git tree: upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=13160026b00000
>>> kernel config: https://syzkaller.appspot.com/x/.config?x=a70237460d215073
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=aa5bebed695edaccf0df
>>> compiler: Debian clang version 11.0.1-2, GNU ld (GNU Binutils for Debian) 2.35.2
>>>
>>> Unfortunately, I don't have any reproducer for this issue yet.
>>>
>>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>>> Reported-by: [email protected]
>>>
>>> ==================================================================
>>> BUG: KCSAN: data-race in flush_tlb_batched_pending / try_to_unmap_one
>>>
>>> write to 0xffff8881072cfbbc of 1 bytes by task 17406 on cpu 1:
>>> flush_tlb_batched_pending+0x5f/0x80 mm/rmap.c:691
>>> madvise_free_pte_range+0xee/0x7d0 mm/madvise.c:594
>>> walk_pmd_range mm/pagewalk.c:128 [inline]
>>> walk_pud_range mm/pagewalk.c:205 [inline]
>>> walk_p4d_range mm/pagewalk.c:240 [inline]
>>> walk_pgd_range mm/pagewalk.c:277 [inline]
>>> __walk_page_range+0x981/0x1160 mm/pagewalk.c:379
>>> walk_page_range+0x131/0x300 mm/pagewalk.c:475
>>> madvise_free_single_vma mm/madvise.c:734 [inline]
>>> madvise_dontneed_free mm/madvise.c:822 [inline]
>>> madvise_vma mm/madvise.c:996 [inline]
>>> do_madvise+0xe4a/0x1140 mm/madvise.c:1202
>>> __do_sys_madvise mm/madvise.c:1228 [inline]
>>> __se_sys_madvise mm/madvise.c:1226 [inline]
>>> __x64_sys_madvise+0x5d/0x70 mm/madvise.c:1226
>>> do_syscall_x64 arch/x86/entry/common.c:50 [inline]
>>> do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80
>>> entry_SYSCALL_64_after_hwframe+0x44/0xae
>>>
>>> write to 0xffff8881072cfbbc of 1 bytes by task 71 on cpu 0:
>>> set_tlb_ubc_flush_pending mm/rmap.c:636 [inline]
>>> try_to_unmap_one+0x60e/0x1220 mm/rmap.c:1515
>>> rmap_walk_anon+0x2fb/0x470 mm/rmap.c:2301
>>> try_to_unmap+0xec/0x110
>>> shrink_page_list+0xe91/0x2620 mm/vmscan.c:1719
>>> shrink_inactive_list+0x3fb/0x730 mm/vmscan.c:2394
>>> shrink_list mm/vmscan.c:2621 [inline]
>>> shrink_lruvec+0x3c9/0x710 mm/vmscan.c:2940
>>> shrink_node_memcgs+0x23e/0x410 mm/vmscan.c:3129
>>> shrink_node+0x8f6/0x1190 mm/vmscan.c:3252
>>> kswapd_shrink_node mm/vmscan.c:4022 [inline]
>>> balance_pgdat+0x702/0xd30 mm/vmscan.c:4213
>>> kswapd+0x200/0x340 mm/vmscan.c:4473
>>> kthread+0x2c7/0x2e0 kernel/kthread.c:327
>>> ret_from_fork+0x1f/0x30
>>>
>>> value changed: 0x01 -> 0x00
>>>
>>> Reported by Kernel Concurrency Sanitizer on:
>>> CPU: 0 PID: 71 Comm: kswapd0 Not tainted 5.16.0-rc1-syzkaller #0
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
>>> ==================================================================
>>
>> Reading 3ea277194daae, I can't quite determine if this is safe and
>> expected.
>>
>> Per this observed write/write race, depending on interleaving
>> tlb_flush_batched can randomly be true or false after
>> set_tlb_ubc_flush_pending().
>>
>> Is this safe?
>>
>
> I do not think it is safe and I am not the only one.
>
> https://lore.kernel.org/linux-mm/[email protected]/
>
> Perhaps Huang has the cycles to fix it.

Yes. I will send out a fix to discuss this soon. Sorry for long delay.

Best Regards,
Huang, Ying