[syzbot] [perf?] KCSAN: data-race in __perf_event_read_value / perf_event_set_state (6)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 5dbeeb268b63 Merge tag 'driver-core-6.19-rc7' of git://git..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=169a105a580000
kernel config: https://syzkaller.appspot.com/x/.config?x=6c9e86480ac654d3
dashboard link: https://syzkaller.appspot.com/bug?extid=6d5529efa784dcc0b926
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/8a4a5a3502b5/disk-5dbeeb26.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/65e86e2ad6af/vmlinux-5dbeeb26.xz
kernel image: https://storage.googleapis.com/syzbot-assets/050ae083081a/bzImage-5dbeeb26.xz

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

==================================================================
BUG: KCSAN: data-race in __perf_event_read_value / perf_event_set_state

write to 0xffff8881311a8538 of 8 bytes by task 13031 on cpu 1:
__perf_update_times kernel/events/core.c:-1 [inline]
perf_event_update_time kernel/events/core.c:735 [inline]
perf_event_set_state+0x1c4/0x440 kernel/events/core.c:754
event_sched_out+0x2d4/0x4d0 kernel/events/core.c:2391
group_sched_out kernel/events/core.c:2415 [inline]
__pmu_ctx_sched_out+0x3e7/0x530 kernel/events/core.c:3458
ctx_sched_out+0x273/0x2d0 kernel/events/core.c:3539
task_ctx_sched_out+0x4d/0x70 kernel/events/core.c:2859
perf_event_context_sched_out kernel/events/core.c:3746 [inline]
__perf_event_task_sched_out+0x2df/0x3c0 kernel/events/core.c:3846
perf_event_task_sched_out include/linux/perf_event.h:1654 [inline]
prepare_task_switch kernel/sched/core.c:5049 [inline]
context_switch kernel/sched/core.c:5205 [inline]
__schedule+0xbaa/0xc90 kernel/sched/core.c:6867
__schedule_loop kernel/sched/core.c:6949 [inline]
schedule+0x5e/0xd0 kernel/sched/core.c:6964
futex_do_wait kernel/futex/waitwake.c:358 [inline]
__futex_wait+0x121/0x260 kernel/futex/waitwake.c:687
futex_wait+0x9c/0x1d0 kernel/futex/waitwake.c:715
do_futex+0x2bf/0x380 kernel/futex/syscalls.c:130
__do_sys_futex kernel/futex/syscalls.c:207 [inline]
__se_sys_futex+0x2f6/0x370 kernel/futex/syscalls.c:188
__x64_sys_futex+0x78/0x90 kernel/futex/syscalls.c:188
x64_sys_call+0x2bc2/0x3000 arch/x86/include/generated/asm/syscalls_64.h:203
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff8881311a8538 of 8 bytes by task 13182 on cpu 0:
__perf_event_read_value+0xb6/0x1d0 kernel/events/core.c:5894
perf_read_one kernel/events/core.c:6049 [inline]
__perf_read kernel/events/core.c:6102 [inline]
perf_read+0x171/0x4f0 kernel/events/core.c:6119
loop_rw_iter+0x2c6/0x3f0 include/linux/uio.h:-1
io_iter_do_read io_uring/rw.c:836 [inline]
__io_read+0xbf6/0xc50 io_uring/rw.c:950
io_read+0x4a/0x190 io_uring/rw.c:1030
__io_issue_sqe+0xfd/0x2d0 io_uring/io_uring.c:1793
io_issue_sqe+0x56/0xa70 io_uring/io_uring.c:1816
io_wq_submit_work+0x3f7/0x5f0 io_uring/io_uring.c:1928
io_worker_handle_work+0x41e/0x950 io_uring/io-wq.c:650
io_wq_worker+0x22d/0x860 io_uring/io-wq.c:704
ret_from_fork+0x148/0x280 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246

value changed: 0x000000004a891b66 -> 0x000000004a89847d

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 13182 Comm: iou-wrk-13031 Not tainted syzkaller #0 PREEMPT(voluntary)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
==================================================================


---
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

[Dmitry Vyukov]

LLM was concerned about the atomicity of these u64 operations on
32-bit systems, and thus concluded the race is harmful.

[Peter Zijlstra]

acquires ctx->lock

> > perf_event_task_sched_out include/linux/perf_event.h:1654 [inline]
> > prepare_task_switch kernel/sched/core.c:5049 [inline]
> > context_switch kernel/sched/core.c:5205 [inline]
> > __schedule+0xbaa/0xc90 kernel/sched/core.c:6867
> > __schedule_loop kernel/sched/core.c:6949 [inline]
> > schedule+0x5e/0xd0 kernel/sched/core.c:6964
> > futex_do_wait kernel/futex/waitwake.c:358 [inline]
> > __futex_wait+0x121/0x260 kernel/futex/waitwake.c:687
> > futex_wait+0x9c/0x1d0 kernel/futex/waitwake.c:715
> > do_futex+0x2bf/0x380 kernel/futex/syscalls.c:130
> > __do_sys_futex kernel/futex/syscalls.c:207 [inline]
> > __se_sys_futex+0x2f6/0x370 kernel/futex/syscalls.c:188
> > __x64_sys_futex+0x78/0x90 kernel/futex/syscalls.c:188
> > x64_sys_call+0x2bc2/0x3000 arch/x86/include/generated/asm/syscalls_64.h:203
> > do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
> > do_syscall_64+0xc0/0x2a0 arch/x86/entry/syscall_64.c:94
> > entry_SYSCALL_64_after_hwframe+0x77/0x7f
> >
> > read to 0xffff8881311a8538 of 8 bytes by task 13182 on cpu 0:
> > __perf_event_read_value+0xb6/0x1d0 kernel/events/core.c:5894
> > perf_read_one kernel/events/core.c:6049 [inline]
> > __perf_read kernel/events/core.c:6102 [inline]

acquires ctx->lock

> > perf_read+0x171/0x4f0 kernel/events/core.c:6119
> > loop_rw_iter+0x2c6/0x3f0 include/linux/uio.h:-1
> > io_iter_do_read io_uring/rw.c:836 [inline]
> > __io_read+0xbf6/0xc50 io_uring/rw.c:950
> > io_read+0x4a/0x190 io_uring/rw.c:1030
> > __io_issue_sqe+0xfd/0x2d0 io_uring/io_uring.c:1793
> > io_issue_sqe+0x56/0xa70 io_uring/io_uring.c:1816
> > io_wq_submit_work+0x3f7/0x5f0 io_uring/io_uring.c:1928
> > io_worker_handle_work+0x41e/0x950 io_uring/io-wq.c:650
> > io_wq_worker+0x22d/0x860 io_uring/io-wq.c:704
> > ret_from_fork+0x148/0x280 arch/x86/kernel/process.c:158
> > ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246
> >
> > value changed: 0x000000004a891b66 -> 0x000000004a89847d
> >
> > Reported by Kernel Concurrency Sanitizer on:
> > CPU: 0 UID: 0 PID: 13182 Comm: iou-wrk-13031 Not tainted syzkaller #0 PREEMPT(voluntary)
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025
> > ==================================================================
>
> LLM was concerned about the atomicity of these u64 operations on
> 32-bit systems, and thus concluded the race is harmful.

I'm not exactly sure I understand how there is a race, things should be
serialized on ctx->lock.