Hi Steven, On 2025-06-26, Steven Rostedt <[email protected]> wrote: >> Your scenario can still happen despite the memory barrier: > > Yes, but the point isn't really to prevent the race. It's more about making > the race window smaller. > > When we disable it, if something is currently using it then it may or may > not get in. That's fine as this isn't critical. > > But from my understanding, without the barriers, some architectures may > never see the update. That is, the write from one CPU may not get to memory > for a long time and new incoming readers will still see the old data. I'm > more concerned with new readers than ones that are currently racing with > the updates.
Memory barriers do not affect visibility. They only affect ordering. And ordering implies that there are at least 2 pieces of data involved. A memory barrier has no meaning when you are only talking about 1 piece of data (in this case @buffer_disabled). For example, update_traceon_count() has an smp_rmb()/smp_wmb() pair to make sure @count updates are ordered to be after @buffer_disabled updates. read(count) smp_rmb() read(buffer_disabled) write(buffer_disabled) smp_wmb() write(count) But what exactly are the memory barriers removed in this patch ordering? John Ogness
