Re: [PATCH] printk: mark racy data block id accesses in the ringbuffer

From: Petr Mladek

Date: Mon Oct 12 2026 - 08:42:37 EST


On Mon 2026-10-12 12:06:47, John Ogness wrote:
> On 2026-10-11, Nguyen Ngoc Thang <ngocthang2710.1999@xxxxxxxxx> wrote:
> > data_alloc() stores the descriptor ID into a newly reserved data block
> > while data_make_reusable(), running from data_push_tail() on another CPU,
> > may still be loading the ID from the same area. The code relies on this
> > race being harmless: a stale or garbage ID simply fails the descriptor
> > lookup or the blk_lpos check. But the accesses are plain, so KCSAN
> > reports them, and the compiler is free to tear or refetch the ID.
> >
> > Use READ_ONCE()/WRITE_ONCE() for every access to the block ID that can
> > overlap with the lockless reader. No functional change intended.
>
> READ_ONCE()/WRITE_ONCE() could cause minor side-effects as it prohibits
> optimizations that do not need to be prohibited. These would not cause a
> problem, but they are unnecessary. The data race is allowed.
>
> How about using data_race() instead?
>
> id = data_race(blk->id);
>
> data_race(blk->id = id);

I prefer data_race() because it makes it clear that the race is
expected. Using READ_ONCE()/READ_ONCE() would create false expectations
that they are needed to prevent some races.

Best Regards,
Petr