On Sat, Aug 17, 2019 at 12:40:40PM -0400, Steven Rostedt wrote: > 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 ;-)
You guys do manage to time these things sometimes. ;-) > 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. For a machine-sized and aligned increment, it is indeed hard to imagine, even for me. I would be more worried about stores of constants with lots of zero bits between non-zero bits on systems with small-sized store-immediate instructions. Thanx, Paul