| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20230126095720.GF5952@tellis.lin.mbt.kalray.eu>
Date: Thu, 26 Jan 2023 10:57:20 +0100
From: Jules Maselbas <jmaselbas@...ray.eu>
To: Mark Rutland <mark.rutland@....com>
Cc: Yann Sionneau <ysionneau@...ray.eu>, Arnd Bergmann <arnd@...db.de>,
Jonathan Corbet <corbet@....net>,
Thomas Gleixner <tglx@...utronix.de>,
Marc Zyngier <maz@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Will Deacon <will@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Boqun Feng <boqun.feng@...il.com>,
Eric Biederman <ebiederm@...ssion.com>,
Kees Cook <keescook@...omium.org>,
Oleg Nesterov <oleg@...hat.com>,
Ingo Molnar <mingo@...hat.com>,
Waiman Long <longman@...hat.com>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.ibm.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Nick Piggin <npiggin@...il.com>,
Paul Moore <paul@...l-moore.com>,
Eric Paris <eparis@...hat.com>,
Christian Brauner <brauner@...nel.org>,
Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>,
Albert Ou <aou@...s.berkeley.edu>,
Guillaume Thouvenin <gthouvenin@...ray.eu>,
Clement Leger <clement@...ment-leger.fr>,
Vincent Chardon <vincent.chardon@...ys-design.com>,
Marc Poulhiès <dkm@...aplop.net>,
Julian Vetter <jvetter@...ray.eu>,
Samuel Jones <sjones@...ray.eu>,
Ashley Lesdalons <alesdalons@...ray.eu>,
Thomas Costis <tcostis@...ray.eu>,
Marius Gligor <mgligor@...ray.eu>,
Jonathan Borne <jborne@...ray.eu>,
Julien Villette <jvillette@...ray.eu>,
Luc Michel <lmichel@...ray.eu>,
Louis Morhet <lmorhet@...ray.eu>,
Julien Hascoet <jhascoet@...ray.eu>,
Jean-Christophe Pince <jcpince@...il.com>,
Guillaume Missonnier <gmissonnier@...ray.eu>,
Alex Michon <amichon@...ray.eu>,
Huacai Chen <chenhuacai@...nel.org>,
WANG Xuerui <git@...0n.name>,
Shaokun Zhang <zhangshaokun@...ilicon.com>,
John Garry <john.garry@...wei.com>,
Guangbin Huang <huangguangbin2@...wei.com>,
Bharat Bhushan <bbhushan2@...vell.com>,
Bibo Mao <maobibo@...ngson.cn>,
Atish Patra <atishp@...shpatra.org>,
"Jason A. Donenfeld" <Jason@...c4.com>,
Qi Liu <liuqi115@...wei.com>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Catalin Marinas <catalin.marinas@....com>,
Mark Brown <broonie@...nel.org>,
Janosch Frank <frankja@...ux.ibm.com>,
Alexey Dobriyan <adobriyan@...il.com>,
Benjamin Mugnier <mugnier.benjamin@...il.com>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org, linux-mm@...ck.org,
linux-arch@...r.kernel.org, linux-audit@...hat.com,
linux-riscv@...ts.infradead.org, bpf@...r.kernel.org
Subject: Re: [RFC PATCH v2 11/31] kvx: Add atomic/locking headers
Hi Mark,
On Fri, Jan 20, 2023 at 03:18:48PM +0000, Mark Rutland wrote:
> On Fri, Jan 20, 2023 at 03:09:42PM +0100, Yann Sionneau wrote:
> > Add common headers (atomic, bitops, barrier and locking) for basic
> > kvx support.
> >
> > Co-developed-by: Clement Leger <clement@...ment-leger.fr>
> > Signed-off-by: Clement Leger <clement@...ment-leger.fr>
> > Co-developed-by: Jules Maselbas <jmaselbas@...ray.eu>
> > Signed-off-by: Jules Maselbas <jmaselbas@...ray.eu>
> > Co-developed-by: Julian Vetter <jvetter@...ray.eu>
> > Signed-off-by: Julian Vetter <jvetter@...ray.eu>
> > Co-developed-by: Julien Villette <jvillette@...ray.eu>
> > Signed-off-by: Julien Villette <jvillette@...ray.eu>
> > Co-developed-by: Yann Sionneau <ysionneau@...ray.eu>
> > Signed-off-by: Yann Sionneau <ysionneau@...ray.eu>
> > ---
> >
> > Notes:
> > V1 -> V2:
> > - use {READ,WRITE}_ONCE for arch_atomic64_{read,set}
> > - use asm-generic/bitops/atomic.h instead of __test_and_*_bit
> > - removed duplicated includes
> > - rewrite xchg and cmpxchg in C using builtins for acswap insn
>
> Thanks for those changes. I see one issue below (instantiated a few times), but
> other than that this looks good to me.
>
> [...]
>
> > +#define ATOMIC64_RETURN_OP(op, c_op) \
> > +static inline long arch_atomic64_##op##_return(long i, atomic64_t *v) \
> > +{ \
> > + long new, old, ret; \
> > + \
> > + do { \
> > + old = v->counter; \
>
> This should be arch_atomic64_read(v), in order to avoid the potential for the
> compiler to replay the access and introduce ABA races and other such problems.
Thanks for the suggestion, this will be into v3.
> For details, see:
>
> https://lore.kernel.org/lkml/Y70SWXHDmOc3RhMd@osiris/
> https://lore.kernel.org/lkml/Y71LoCIl+IFdy9D8@FVFF77S0Q05N/
>
> I see that the generic 32-bit atomic code suffers from that issue, and we
> should fix it.
I took a look at the generic 32-bit atomic, but I am unsure if this
needs to be done for both the SMP and non-SMP implementations. But I
can send a first patch and we can discuss from there.
> > + new = old c_op i; \
> > + ret = arch_cmpxchg(&v->counter, old, new); \
> > + } while (ret != old); \
> > + \
> > + return new; \
> > +}
> > +
> > +#define ATOMIC64_OP(op, c_op) \
> > +static inline void arch_atomic64_##op(long i, atomic64_t *v) \
> > +{ \
> > + long new, old, ret; \
> > + \
> > + do { \
> > + old = v->counter; \
>
> Likewise, arch_atomic64_read(v) here.
ack
> > + new = old c_op i; \
> > + ret = arch_cmpxchg(&v->counter, old, new); \
> > + } while (ret != old); \
> > +}
> > +
> > +#define ATOMIC64_FETCH_OP(op, c_op) \
> > +static inline long arch_atomic64_fetch_##op(long i, atomic64_t *v) \
> > +{ \
> > + long new, old, ret; \
> > + \
> > + do { \
> > + old = v->counter; \
>
> Likewise, arch_atomic64_read(v) here.
ack
> > + new = old c_op i; \
> > + ret = arch_cmpxchg(&v->counter, old, new); \
> > + } while (ret != old); \
> > + \
> > + return old; \
> > +}
> > +
> > +#define ATOMIC64_OPS(op, c_op) \
> > + ATOMIC64_OP(op, c_op) \
> > + ATOMIC64_RETURN_OP(op, c_op) \
> > + ATOMIC64_FETCH_OP(op, c_op)
> > +
> > +ATOMIC64_OPS(and, &)
> > +ATOMIC64_OPS(or, |)
> > +ATOMIC64_OPS(xor, ^)
> > +ATOMIC64_OPS(add, +)
> > +ATOMIC64_OPS(sub, -)
> > +
> > +#undef ATOMIC64_OPS
> > +#undef ATOMIC64_FETCH_OP
> > +#undef ATOMIC64_OP
> > +
> > +static inline int arch_atomic_add_return(int i, atomic_t *v)
> > +{
> > + int new, old, ret;
> > +
> > + do {
> > + old = v->counter;
>
> Likewise, arch_atomic64_read(v) here.
ack, this will bt arch_atomic_read(v) here since this is not atomic64_t
here.
Thanks
-- Jules
Powered by blists - more mailing lists