linux-kernel - Re: [RFC PATCH v2 11/31] kvx: Add atomic/locking headers

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20230126111957.GG5952@tellis.lin.mbt.kalray.eu>
Date:   Thu, 26 Jan 2023 12:19:57 +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

On Thu, Jan 26, 2023 at 10:57:20AM +0100, Jules Maselbas wrote:
> Hi Mark,
...

> > > +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.
I took a second look at this and I think we are not doing the right
thing, we do not need to defined arch_atomic_add_return at all since
we are including the generic atomic right after, which will define
the macro arch_atomic_add_return as generic_atomic_add_return

> 
> Thanks
> -- Jules
> 
> 
> 
> 
> 
> 
> 
> 
>