[syzbot] [kernel?] KCSAN: data-race in pcpu_alloc_noprof / pcpu_balance_workfn (2)

8 views
Skip to first unread message

syzbot

unread,
Aug 29, 2024, 12:53:22 PMAug 29
to b...@alien8.de, dave....@linux.intel.com, h...@zytor.com, linux-...@vger.kernel.org, mi...@redhat.com, syzkall...@googlegroups.com, tg...@linutronix.de, x...@kernel.org
Hello,

syzbot found the following issue on:

HEAD commit: d5d547aa7b51 Merge tag 'random-6.11-rc6-for-linus' of git:..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=164c067b980000
kernel config: https://syzkaller.appspot.com/x/.config?x=6fafac02e339cc84
dashboard link: https://syzkaller.appspot.com/bug?extid=6d392a44667baa45bb5a
compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/e636aa58c364/disk-d5d547aa.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/f5ecd0d96afa/vmlinux-d5d547aa.xz
kernel image: https://storage.googleapis.com/syzbot-assets/fe7d474f148f/bzImage-d5d547aa.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+6d392a...@syzkaller.appspotmail.com

==================================================================
BUG: KCSAN: data-race in pcpu_alloc_noprof / pcpu_balance_workfn

read-write to 0xffffffff88bb27ac of 4 bytes by task 3354 on cpu 0:
pcpu_update_empty_pages mm/percpu.c:602 [inline]
pcpu_chunk_populated mm/percpu.c:1531 [inline]
pcpu_balance_populated mm/percpu.c:2062 [inline]
pcpu_balance_workfn+0x94e/0xa60 mm/percpu.c:2212
process_one_work kernel/workqueue.c:3231 [inline]
process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3312
worker_thread+0x526/0x6e0 kernel/workqueue.c:3389
kthread+0x1d1/0x210 kernel/kthread.c:389
ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244

read to 0xffffffff88bb27ac of 4 bytes by task 6821 on cpu 1:
pcpu_alloc_noprof+0x9a7/0x10c0 mm/percpu.c:1894
bpf_map_alloc_percpu+0xad/0x210 kernel/bpf/syscall.c:466
prealloc_init+0x19f/0x470 kernel/bpf/hashtab.c:341
htab_map_alloc+0x630/0x8e0 kernel/bpf/hashtab.c:576
map_create+0x83c/0xb90 kernel/bpf/syscall.c:1333
__sys_bpf+0x667/0x7a0 kernel/bpf/syscall.c:5692
__do_sys_bpf kernel/bpf/syscall.c:5817 [inline]
__se_sys_bpf kernel/bpf/syscall.c:5815 [inline]
__x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5815
x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0x00000001 -> 0x00000004

Reported by Kernel Concurrency Sanitizer on:
CPU: 1 UID: 0 PID: 6821 Comm: syz.4.1651 Not tainted 6.11.0-rc5-syzkaller-00081-gd5d547aa7b51 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
==================================================================


---
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 syzk...@googlegroups.com.

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

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

Thomas Gleixner

unread,
Sep 2, 2024, 4:26:13 AMSep 2
to syzbot, linux-...@vger.kernel.org, syzkall...@googlegroups.com, x...@kernel.org, linu...@kvack.org
On Thu, Aug 29 2024 at 09:53, syzbot wrote:

Cc-: x86 folks. Just because something happens on x86 does not mean it's
an x86 problem

Cc+: mm folks. It's entirely clear where this belongs to:

> read-write to 0xffffffff88bb27ac of 4 bytes by task 3354 on cpu 0:
> pcpu_update_empty_pages mm/percpu.c:602 [inline]

No?

Dennis Zhou

unread,
Sep 3, 2024, 6:11:07 PMSep 3
to Thomas Gleixner, syzbot, linux-...@vger.kernel.org, syzkall...@googlegroups.com, x...@kernel.org, linu...@kvack.org
On Mon, Sep 02, 2024 at 10:26:10AM +0200, Thomas Gleixner wrote:
> On Thu, Aug 29 2024 at 09:53, syzbot wrote:
>
> Cc-: x86 folks. Just because something happens on x86 does not mean it's
> an x86 problem
>
> Cc+: mm folks. It's entirely clear where this belongs to:
>
> > read-write to 0xffffffff88bb27ac of 4 bytes by task 3354 on cpu 0:
> > pcpu_update_empty_pages mm/percpu.c:602 [inline]
>
> No?
>

Yeah.. We discussed this a month ago [1], I just haven't had time. I'll
send out the fix for this tonight/tmrw morning.


Thanks,
Dennis

[1] https://lore.kernel.org/lkml/ZqCo7H2gcA1dvIr4@xsang-OptiPlex-9020/
Reply all
Reply to author
Forward
0 new messages