Re: MUTEX_CAS() and memory barriers

[Rin Okuyama <rokuyama.rk%gmail.com@localhost>]

On 2021/07/25 22:07, Jason Thorpe wrote:
> > On Jul 25, 2021, at 1:58 AM, Martin Husemann <martin%duskware.de@localhost> wrote:
> >
> > On Sat, Jul 24, 2021 at 05:59:59PM -0700, Jason Thorpe wrote:
> > > Anyway, I?m much more concerned with (1).  I think at the very least, alpha and sparc64 don?t need to define their own _lock_cas() and can just use atomic_cas_ulong()? furthermore, I think we can just let that be the default definition unless a platform has a REALLY good reason to override it (I mean, not even sh3 has to do so, because it aliases _lock_cas() to atomic_cas_ulong()).
> >
> > Sounds good.
> >
> > I wonder if there is some easy trick to make the ppc thing patchable for
> > non-affected machines (or is that already done?)
>
> I’m not familiar with the specific errata …. It’s not hot-patched, but it is #ifdef’d I’m sure.  I need to spend a little more time looking, but I assume it would apply to the not-_lock_cas() atomic_cas_*() functions, too.

For kernel, PPC errata is worked around only for affected machines
(a part of IBM405 family processors) by compile-time option.

Thanks,
rin