[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zl0RQC4br7KoaGlC@andrea>
Date: Mon, 3 Jun 2024 02:41:36 +0200
From: Andrea Parri <parri.andrea@...il.com>
To: Guo Ren <guoren@...nel.org>
Cc: Alexandre Ghiti <alex@...ti.fr>,
Alexandre Ghiti <alexghiti@...osinc.com>,
Jonathan Corbet <corbet@....net>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>, Boqun Feng <boqun.feng@...il.com>,
Arnd Bergmann <arnd@...db.de>, Leonardo Bras <leobras@...hat.com>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 7/7] riscv: Add qspinlock support based on Zabha extension
> I looked at the riscv-unprivileged ppo section, seems RISC-V .rl ->
> .aq has RCsc annotations.
> ref:
> Explicit Synchronization
> 5. has an acquire annotation
> 6. has a release annotation
> 7. a and b both have RCsc annotations
>
> And for qspinlock:
> unlock:
> smp_store_release(&lock->locked, 0);
>
> lock:
> if (likely(atomic_try_cmpxchg_acquire(&lock->val, &val, _Q_LOCKED_VAL)))
>
> If the hardware has Store-Release and CAS instructions, they all obey
> Explicit Synchronization rules. Then RISC-V "UNLOCK+LOCK" pairs act as
> a full barrier, right?
Presuming you were thinking at CAS.aq (based on your previous remarks
above), that all seems right to me. In fact, the (putative) Store.rl
and an LR.aq would also do it (by the same/mentioned rules).
Andrea
Powered by blists - more mailing lists