[syzbot] [trace?] KCSAN: data-race in ring_buffer_unlock_commit / ring_buffer_unlock_commit

[syzbot] [trace?] KCSAN: data-race in ring_buffer_unlock_commit / ring_buffer_unlock_commit

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:    848acc8ffe1b Merge tag 'fsverity-for-linus' of git://git.k..
git tree:       upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13731649580000
kernel config:  https://syzkaller.appspot.com/x/.config?x=84b3039e8461eef5
dashboard link: https://syzkaller.appspot.com/bug?extid=0168fe25f9e5d46bd5fe
compiler:       Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8

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

Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/d1a0ae21bd78/disk-848acc8f.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/9be505d18eb6/vmlinux-848acc8f.xz
kernel image: https://storage.googleapis.com/syzbot-assets/8ab6a3838bc0/bzImage-848acc8f.xz

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

==================================================================
BUG: KCSAN: data-race in ring_buffer_unlock_commit / ring_buffer_unlock_commit

write to 0xffff888100074cb4 of 1 bytes by task 8271 on cpu 1:
 rb_wakeups kernel/trace/ring_buffer.c:4295 [inline]
 ring_buffer_unlock_commit+0x6a/0x440 kernel/trace/ring_buffer.c:4495
 __buffer_unlock_commit kernel/trace/trace.h:1697 [inline]
 trace_buffer_unlock_commit_regs+0x43/0x310 kernel/trace/trace.c:2049
 trace_event_buffer_commit+0x149/0x590 kernel/trace/trace.c:2024
 do_trace_event_raw_event_hrtimer_setup include/trace/events/timer.h:193 [inline]
 trace_event_raw_event_hrtimer_setup+0xc9/0x170 include/trace/events/timer.h:193
 __do_trace_hrtimer_setup include/trace/events/timer.h:193 [inline]
 trace_hrtimer_setup include/trace/events/timer.h:193 [inline]
 debug_setup_on_stack kernel/time/hrtimer.c:523 [inline]
 hrtimer_setup_sleeper_on_stack+0xd1/0xf0 kernel/time/hrtimer.c:2366
 schedule_hrtimeout_range_clock+0x71/0x1a0 kernel/time/sleep_timeout.c:211
 schedule_hrtimeout_range+0x28/0x40 kernel/time/sleep_timeout.c:263
 poll_schedule_timeout fs/select.c:241 [inline]
 do_select+0xed3/0xfa0 fs/select.c:603
 core_sys_select+0x453/0x730 fs/select.c:677
 do_pselect fs/select.c:770 [inline]
 __do_sys_pselect6 fs/select.c:809 [inline]
 __se_sys_pselect6+0x23f/0x2a0 fs/select.c:800
 __x64_sys_pselect6+0x78/0x90 fs/select.c:800
 x64_sys_call+0x8d5/0x3020 arch/x86/include/generated/asm/syscalls_64.h:271
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x136/0x3c0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

read to 0xffff888100074cb4 of 1 bytes by task 8264 on cpu 0:
 rb_wakeups kernel/trace/ring_buffer.c:4294 [inline]
 ring_buffer_unlock_commit+0x54/0x440 kernel/trace/ring_buffer.c:4495
 __buffer_unlock_commit kernel/trace/trace.h:1697 [inline]
 trace_buffer_unlock_commit_regs+0x43/0x310 kernel/trace/trace.c:2049
 trace_event_buffer_commit+0x149/0x590 kernel/trace/trace.c:2024
 do_trace_event_raw_event_sock_msg_length include/trace/events/sock.h:267 [inline]
 trace_event_raw_event_sock_msg_length+0x10f/0x1c0 include/trace/events/sock.h:267
 __do_trace_sock_recv_length include/trace/events/sock.h:304 [inline]
 trace_sock_recv_length include/trace/events/sock.h:304 [inline]
 call_trace_sock_recv_length+0xa2/0xc0 net/socket.c:1120
 sock_recvmsg_nosec+0xdf/0xf0 net/socket.c:1131
 ____sys_recvmsg+0x26f/0x280 net/socket.c:2902
 ___sys_recvmsg+0x11f/0x3a0 net/socket.c:2946
 do_recvmmsg+0x1e5/0x560 net/socket.c:3041
 __sys_recvmmsg net/socket.c:3115 [inline]
 __do_sys_recvmmsg net/socket.c:3138 [inline]
 __se_sys_recvmmsg net/socket.c:3131 [inline]
 __x64_sys_recvmmsg+0xe5/0x170 net/socket.c:3131
 x64_sys_call+0x80f/0x3020 arch/x86/include/generated/asm/syscalls_64.h:300
 do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
 do_syscall_64+0x136/0x3c0 arch/x86/entry/syscall_64.c:94
 entry_SYSCALL_64_after_hwframe+0x77/0x7f

value changed: 0x01 -> 0x00

Reported by Kernel Concurrency Sanitizer on:
CPU: 0 UID: 0 PID: 8264 Comm: syz.5.1654 Not tainted syzkaller #0 PREEMPT(lazy) 
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
==================================================================


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

Re: [syzbot] [trace?] KCSAN: data-race in ring_buffer_unlock_commit / ring_buffer_unlock_commit

[Steven Rostedt]

On Mon, 03 Aug 2026 19:50:31 -0700
syzbot <syzbot+0168fe25f9e5d46bd5fe@syzkaller.appspotmail.com> wrote:

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

Looks to be a false positive.

> 
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/d1a0ae21bd78/disk-848acc8f.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/9be505d18eb6/vmlinux-848acc8f.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/8ab6a3838bc0/bzImage-848acc8f.xz
> 
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+0168fe25f9e5d46bd5fe@syzkaller.appspotmail.com
> 
> ==================================================================
> BUG: KCSAN: data-race in ring_buffer_unlock_commit / ring_buffer_unlock_commit
> 
> write to 0xffff888100074cb4 of 1 bytes by task 8271 on cpu 1:
>  rb_wakeups kernel/trace/ring_buffer.c:4295 [inline]
>  ring_buffer_unlock_commit+0x6a/0x440 kernel/trace/ring_buffer.c:4495
>  __buffer_unlock_commit kernel/trace/trace.h:1697 [inline]

> 
> read to 0xffff888100074cb4 of 1 bytes by task 8264 on cpu 0:
>  rb_wakeups kernel/trace/ring_buffer.c:4294 [inline]
>  ring_buffer_unlock_commit+0x54/0x440 kernel/trace/ring_buffer.c:4495
>  __buffer_unlock_commit kernel/trace/trace.h:1697 [inline]


> 
> value changed: 0x01 -> 0x00
> 

The code is this:

        if (buffer->irq_work.waiters_pending) {
                buffer->irq_work.waiters_pending = false;
                /* irq_work_queue() supplies it's own memory barriers */
                rb_irq_work_queue(&buffer->irq_work);
        }

The detection is against the reading of waiters_pending and setting of
it. When a task is waiting for data, it will set waiters_pending when
there should be a wake up, and it doesn't need to be woken up
immediately. The first writer that sees this set will call the
irq_work_queue() which has all the necessary memory barriers needed to
make sure it is queued properly. But we do not care about this data
race here. We do not need to have memory barriers here because this is
a "lazy" call. That is, it doesn't hurt if it misses the check or
multiple tasks enable it here. Things will work out later.

I guess the "fix" is to quiet this warning.

-- Steve