Re: [for-next][PATCH 2/2] atomic64: Use arch_spin_locks instead of raw_spin_locks

[Peter Zijlstra]

On Wed, Jan 22, 2025 at 10:55:17AM -0500, Steven Rostedt wrote:

> > >  s64 generic_atomic64_read(const atomic64_t *v)
> > >  {
> > >  	unsigned long flags;
> > > -	raw_spinlock_t *lock = lock_addr(v);
> > > +	arch_spinlock_t *lock = lock_addr(v);
> > >  	s64 val;
> > >  
> > > -	raw_spin_lock_irqsave(lock, flags);
> > > +	local_irq_save(flags);
> > > +	arch_spin_lock(lock);  
> > 
> > Note that this is not an equivalent change. It's probably sufficient,
> > but at the very least the Changelog should call out what went missing
> > and how that is okay.
> 
> What exactly is the difference here that you are talking about? I know that
> raw_spin_lock_irqsave() has lots of different variants depending on the
> config options, but I'm not sure which you are talking about? Is it the fact
> that you can't do the different variants with this?

If I followed the maze right, then I get something like:

raw_spin_lock_irqsave(lock, flags)
  local_irq_save(flags);
  preempt_disable();
  arch_spin_lock(lock);
  mmiowb_spin_lock();


And here you leave out that preempt_disable() and mmiowb stuff. The
former is fine because local_irq_save() already makes things
non-preemptible and there are no irq-state games. The mmiowb thing is
fine because nothing inside this critical section cares about mmio.