On Sat, 17 Aug 2019 11:55:17 -0400 (EDT) Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote:
> ----- On Aug 17, 2019, at 11:26 AM, rostedt rost...@goodmis.org wrote: > > > On Sat, 17 Aug 2019 10:40:31 -0400 (EDT) > > Mathieu Desnoyers <mathieu.desnoy...@efficios.com> wrote: > > > >> > I'm now even more against adding the READ_ONCE() or WRITE_ONCE(). > >> > >> I'm not convinced by your arguments. > > > > Prove to me that there's an issue here beyond theoretical analysis, > > then I'll consider that patch. > > > > Show me a compiler used to compile the kernel that zeros out the > > increment. Show me were the race actually occurs. > > > > I think the READ/WRITE_ONCE() is more confusing than helpful. And > > unneeded churn to the code. And really not needed for something that's > > not critical to execution. > > I'll have to let the authors of the LWN article speak up on this, because > I have limited time to replicate this investigation myself. I'll let Paul McKenney convince me then, if he has any spare cycles ;-) The one instance in that article is from a 2013 bug, which talks about storing a 64 bit value on a 32 bit machine. But the ref count is an int (32 bit), and I highly doubt any compiler will split it into 16 bit stores for a simple increment. And I don't believe Linux even supports any architecture that requires 16 bit stores anymore. -- Steve
