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: <ZBpPms0PGv4sWR1Y@andrea>
Date:   Wed, 22 Mar 2023 01:45:14 +0100
From:   Andrea Parri <parri.andrea@...il.com>
To:     Leonardo Bras <leobras@...hat.com>
Cc:     Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>, Guo Ren <guoren@...nel.org>,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND RFC PATCH v2 1/6] riscv/cmpxchg: Deduplicate cmpxchg()
 asm functions

On Tue, Mar 21, 2023 at 04:42:44AM -0300, Leonardo Bras wrote:
> In this header every cmpxchg define (_relaxed, _acquire, _release,
> vanilla) contain it's own asm file, both for 4-byte variables an 8-byte
> variables, on a total of 8 versions of mostly the same asm.
> 
> This is usually bad, as it means any change may be done in up to 8
> different places.
> 
> Unify those versions by creating a new define with enough parameters to
> generate any version of the previous 8.
> 
> (This did not cause any change in generated asm)
> 
> Signed-off-by: Leonardo Bras <leobras@...hat.com>
> ---
>  arch/riscv/include/asm/cmpxchg.h | 102 ++++++++-----------------------
>  1 file changed, 24 insertions(+), 78 deletions(-)

Diff looks nice,


> +#define ___cmpxchg(lr_sfx, sc_sfx, prepend, append)			\
> +{									\
> +	__asm__ __volatile__ (						\
> +		prepend							\
> +		"0:	lr" lr_sfx " %0, %2\n"				\
> +		"	bne  %0, %z3, 1f\n"				\
> +		"	sc" sc_sfx " %1, %z4, %2\n"			\
> +		"	bnez %1, 0b\n"					\
> +		append							\
> +		"1:\n"							\
> +		: "=&r" (__ret), "=&r" (__rc), "+A" (*__ptr)		\
> +		: "rJ" ((long)__old), "rJ" (__new)			\
> +		: "memory");						\
> +}

Though I'm not really a fan of macros depending on local variables with
"magic" names, can this be avoided?

Thanks,
  Andrea

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ