[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260206091621.GO1395266@noisy.programming.kicks-ass.net>
Date: Fri, 6 Feb 2026 10:16:21 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Dmitry Vyukov <dvyukov@...gle.com>
Cc: syzbot <syzbot+6d5529efa784dcc0b926@...kaller.appspotmail.com>,
acme@...nel.org, adrian.hunter@...el.com,
alexander.shishkin@...ux.intel.com, irogers@...gle.com,
james.clark@...aro.org, jolsa@...nel.org,
linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
mark.rutland@....com, mingo@...hat.com, namhyung@...nel.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [perf?] KCSAN: data-race in __perf_event_read_value /
perf_event_set_state (6)
On Fri, Feb 06, 2026 at 08:37:14AM +0100, Dmitry Vyukov wrote:
> On Fri, 6 Feb 2026 at 08:34, syzbot
> <syzbot+6d5529efa784dcc0b926@...kaller.appspotmail.com> wrote:
> >
> > 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+6d5529efa784dcc0b926@...kaller.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
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.
Powered by blists - more mailing lists