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

[Steven Rostedt <rostedt@goodmis.org>]

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