Re: [RFC] Potential problem in qspinlock due to mixed-size accesses

[Paul E. McKenney]

On Tue, Jun 17, 2025 at 11:51:49PM -0700, Paul E. McKenney wrote:
> On Fri, Jun 13, 2025 at 09:55:01AM +0200, Peter Zijlstra wrote:
> > On Thu, Jun 12, 2025 at 04:55:28PM +0200, Thomas Haas wrote:
> 
> [ . . . ]
> 
> > >     - put some other read-read barrier between the xchg_tail and the load.
> > > 
> > > 
> > > ### Implications for qspinlock executed on non-ARM architectures.
> > > 
> > > Unfortunately, there are no MSA extensions for other hardware memory models,
> > > so we have to speculate based on whether the problematic reordering is
> > > permitted if the problematic load was treated as two individual
> > > instructions.
> > > It seems Power and RISCV would have no problem reordering the instructions,
> > > so qspinlock might also break on those architectures.
> > 
> > Power (and RiscV without ZABHA) 'emulate' the short XCHG using a full
> > word LL/SC and should be good.
> > 
> > But yes, ZABHA might be equally broken.
> 
> All architectures handle eight-bit atomics and stores, but last I checked,
> there were a few systems still around that failed to support 16-bit
> atomics and stores.  I will check again.
> 
> (But those systems's architectures can simply avoid supporting kernel
> features requiring these 16-bit operations.)
> 
> It would be good to add multiple sizes to LKMM, and even moreso once we
> have 16-bit support across the board.

And Arnd tells me that the Linux kernel might be safe for 16-bit stores
in core code perhaps as early as the end of this year.  ;-)

							Thanx, Paul