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: <2E96A836-764D-4D07-AB79-3861B9CC2B1F@jrtc27.com>
Date:   Thu, 22 Sep 2022 16:52:46 +0100
From:   Jessica Clarke <jrtc27@...c27.com>
To:     Heiko Stuebner <heiko@...ech.de>
Cc:     Palmer Dabbelt <palmer@...belt.com>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Samuel Holland <samuel@...lland.org>,
        Albert Ou <aou@...s.berkeley.edu>,
        Anup Patel <anup@...infault.org>,
        Atish Patra <atishp@...osinc.com>, Dao Lu <daolu@...osinc.com>,
        Guo Ren <guoren@...nel.org>,
        Jisheng Zhang <jszhang@...nel.org>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] riscv: Fix build with CONFIG_CC_OPTIMIZE_FOR_SIZE=y

On 22 Sept 2022, at 16:45, Heiko Stuebner <heiko@...ech.de> wrote:
> 
> Am Donnerstag, 22. September 2022, 08:09:58 CEST schrieb Samuel Holland:
>> commit 8eb060e10185 ("arch/riscv: add Zihintpause support") broke
>> building with CONFIG_CC_OPTIMIZE_FOR_SIZE enabled (gcc 11.1.0):
>> 
>> CC arch/riscv/kernel/vdso/vgettimeofday.o
>> In file included from <command-line>:
>> ./arch/riscv/include/asm/jump_label.h: In function 'cpu_relax':
>> ././include/linux/compiler_types.h:285:33: warning: 'asm' operand 0 probably does not match constraints
>> 285 | #define asm_volatile_goto(x...) asm goto(x)
>> | ^~~
>> ./arch/riscv/include/asm/jump_label.h:41:9: note: in expansion of macro 'asm_volatile_goto'
>> 41 | asm_volatile_goto(
>> | ^~~~~~~~~~~~~~~~~
>> ././include/linux/compiler_types.h:285:33: error: impossible constraint in 'asm'
>> 285 | #define asm_volatile_goto(x...) asm goto(x)
>> | ^~~
>> ./arch/riscv/include/asm/jump_label.h:41:9: note: in expansion of macro 'asm_volatile_goto'
>> 41 | asm_volatile_goto(
>> | ^~~~~~~~~~~~~~~~~
>> make[1]: *** [scripts/Makefile.build:249: arch/riscv/kernel/vdso/vgettimeofday.o] Error 1
>> make: *** [arch/riscv/Makefile:128: vdso_prepare] Error 2
>> 
>> Having a static branch in cpu_relax() is problematic because that
>> function is widely inlined, including in some quite complex functions
>> like in the VDSO. A quick measurement shows this static branch is
>> responsible by itself for around 40% of the jump table.
>> 
>> Drop the static branch, which ends up being the same number of
>> instructions anyway. If Zihintpause is supported, we trade the nop from
>> the static branch for a div. If Zihintpause is unsupported, we trade the
>> jump from the static branch for (what gets interpreted as) a nop.
>> 
>> Fixes: 8eb060e10185 ("arch/riscv: add Zihintpause support")
>> Signed-off-by: Samuel Holland <samuel@...lland.org>
>> ---
>> 
>> arch/riscv/include/asm/hwcap.h | 3 ---
>> arch/riscv/include/asm/vdso/processor.h | 25 ++++++++++---------------
>> 2 files changed, 10 insertions(+), 18 deletions(-)
>> 
>> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
>> index 6f59ec64175e..b21d46e68386 100644
>> --- a/arch/riscv/include/asm/hwcap.h
>> +++ b/arch/riscv/include/asm/hwcap.h
>> @@ -68,7 +68,6 @@ enum riscv_isa_ext_id {
>> */
>> enum riscv_isa_ext_key {
>> 	RISCV_ISA_EXT_KEY_FPU,		/* For 'F' and 'D' */
>> -	RISCV_ISA_EXT_KEY_ZIHINTPAUSE,
>> 	RISCV_ISA_EXT_KEY_MAX,
>> };
>> 
>> @@ -88,8 +87,6 @@ static __always_inline int riscv_isa_ext2key(int num)
>> 		return RISCV_ISA_EXT_KEY_FPU;
>> 	case RISCV_ISA_EXT_d:
>> 		return RISCV_ISA_EXT_KEY_FPU;
>> -	case RISCV_ISA_EXT_ZIHINTPAUSE:
>> -		return RISCV_ISA_EXT_KEY_ZIHINTPAUSE;
>> 	default:
>> 		return -EINVAL;
>> 	}
>> diff --git a/arch/riscv/include/asm/vdso/processor.h b/arch/riscv/include/asm/vdso/processor.h
>> index 1e4f8b4aef79..789bdb8211a2 100644
>> --- a/arch/riscv/include/asm/vdso/processor.h
>> +++ b/arch/riscv/include/asm/vdso/processor.h
>> @@ -4,30 +4,25 @@
>> 
>> #ifndef __ASSEMBLY__
>> 
>> -#include <linux/jump_label.h>
>> #include <asm/barrier.h>
>> -#include <asm/hwcap.h>
>> 
>> static inline void cpu_relax(void)
>> {
>> -	if (!static_branch_likely(&riscv_isa_ext_keys[RISCV_ISA_EXT_KEY_ZIHINTPAUSE])) {
>> #ifdef __riscv_muldiv
>> -		int dummy;
>> -		/* In lieu of a halt instruction, induce a long-latency stall. */
>> -		__asm__ __volatile__ ("div %0, %0, zero" : "=r" (dummy));
>> +	int dummy;
>> +	/* In lieu of a halt instruction, induce a long-latency stall. */
>> +	__asm__ __volatile__ ("div %0, %0, zero" : "=r" (dummy));
>> #endif
>> -	} else {
>> -		/*
>> -		 * Reduce instruction retirement.
>> -		 * This assumes the PC changes.
>> -		 */
>> +	/*
>> +	 * Reduce instruction retirement.
>> +	 * This assumes the PC changes.
>> +	 */
>> #ifdef __riscv_zihintpause
>> -		__asm__ __volatile__ ("pause");
>> +	__asm__ __volatile__ ("pause");
>> #else
>> -		/* Encoding of the pause instruction */
>> -		__asm__ __volatile__ (".4byte 0x100000F");
>> +	/* Encoding of the pause instruction */
>> +	__asm__ __volatile__ (".4byte 0x100000F");
>> #endif
> 
> hmm, though before this part of the code was only ever accessed
> when the zhintpause extension was really available on the running
> machine while now the pause instruction is called every time.
> 
> So I'm just wondering, can't this run into some "illegal instruction"
> thingy on machines not supporting the extension?

No. The encoding for pause was deliberately chosen to be one of the
“useless” encodings of fence, with the hope that existing
microarchitectures might take a while to execute it and thus it would
still function as a slow-running instruction. It’s somewhat
questionable whether the div is even needed, the worst that happens is
cpu_relax isn’t very relaxed and you spin a bit faster. Any
implementations where that’s true probably also don’t have fancy
clock/power management anyway, and div isn’t going to be a low-power
operation so the only real effect is likely hammering on contended
atomics a bit more, and who cares about that on the low core count
systems we have today.

Jess

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ