* [PATCH v2 0/4] riscv: Add Zalasr ISA extension support
@ 2025-09-02 4:24 Xu Lu
2025-09-02 4:24 ` [PATCH v2 1/4] riscv: add ISA extension parsing for Zalasr Xu Lu
` (4 more replies)
0 siblings, 5 replies; 18+ messages in thread
From: Xu Lu @ 2025-09-02 4:24 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones,
brs
Cc: devicetree, linux-riscv, linux-kernel, apw, joe, Xu Lu
This patch adds support for the Zalasr ISA extension, which supplies the
real load acquire/store release instructions.
The specification can be found here:
https://github.com/riscv/riscv-zalasr/blob/main/chapter2.adoc
This patch seires has been tested with ltp on Qemu with Brensan's zalasr
support patch[1].
Some false positive spacing error happens during patch checking. Thus I
CCed maintainers of checkpatch.pl as well.
[1] https://lore.kernel.org/all/CAGPSXwJEdtqW=nx71oufZp64nK6tK=0rytVEcz4F-gfvCOXk2w@mail.gmail.com/
v2:
- Adjust the order of Zalasr and Zalrsc in dt-bindings. Thanks to
Conor.
Xu Lu (4):
riscv: add ISA extension parsing for Zalasr
dt-bindings: riscv: Add Zalasr ISA extension description
riscv: Instroduce Zalasr instructions
riscv: Use Zalasr for smp_load_acquire/smp_store_release
.../devicetree/bindings/riscv/extensions.yaml | 5 ++
arch/riscv/include/asm/barrier.h | 79 ++++++++++++++++---
arch/riscv/include/asm/hwcap.h | 1 +
arch/riscv/include/asm/insn-def.h | 79 +++++++++++++++++++
arch/riscv/kernel/cpufeature.c | 1 +
5 files changed, 154 insertions(+), 11 deletions(-)
--
2.20.1
^ permalink raw reply [flat|nested] 18+ messages in thread* [PATCH v2 1/4] riscv: add ISA extension parsing for Zalasr 2025-09-02 4:24 [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Xu Lu @ 2025-09-02 4:24 ` Xu Lu 2025-09-02 4:24 ` [PATCH v2 2/4] dt-bindings: riscv: Add Zalasr ISA extension description Xu Lu ` (3 subsequent siblings) 4 siblings, 0 replies; 18+ messages in thread From: Xu Lu @ 2025-09-02 4:24 UTC (permalink / raw) To: robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs Cc: devicetree, linux-riscv, linux-kernel, apw, joe, Xu Lu Add parsing for Zalasr ISA extension. Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> --- arch/riscv/include/asm/hwcap.h | 1 + arch/riscv/kernel/cpufeature.c | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h index affd63e11b0a3..ae3852c4f2ca2 100644 --- a/arch/riscv/include/asm/hwcap.h +++ b/arch/riscv/include/asm/hwcap.h @@ -106,6 +106,7 @@ #define RISCV_ISA_EXT_ZAAMO 97 #define RISCV_ISA_EXT_ZALRSC 98 #define RISCV_ISA_EXT_ZICBOP 99 +#define RISCV_ISA_EXT_ZALASR 100 #define RISCV_ISA_EXT_XLINUXENVCFG 127 diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c index 743d53415572e..bf9d3d92bf372 100644 --- a/arch/riscv/kernel/cpufeature.c +++ b/arch/riscv/kernel/cpufeature.c @@ -472,6 +472,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = { __RISCV_ISA_EXT_DATA(zaamo, RISCV_ISA_EXT_ZAAMO), __RISCV_ISA_EXT_DATA(zabha, RISCV_ISA_EXT_ZABHA), __RISCV_ISA_EXT_DATA(zacas, RISCV_ISA_EXT_ZACAS), + __RISCV_ISA_EXT_DATA(zalasr, RISCV_ISA_EXT_ZALASR), __RISCV_ISA_EXT_DATA(zalrsc, RISCV_ISA_EXT_ZALRSC), __RISCV_ISA_EXT_DATA(zawrs, RISCV_ISA_EXT_ZAWRS), __RISCV_ISA_EXT_DATA(zfa, RISCV_ISA_EXT_ZFA), -- 2.20.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v2 2/4] dt-bindings: riscv: Add Zalasr ISA extension description 2025-09-02 4:24 [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Xu Lu 2025-09-02 4:24 ` [PATCH v2 1/4] riscv: add ISA extension parsing for Zalasr Xu Lu @ 2025-09-02 4:24 ` Xu Lu 2025-09-02 19:46 ` Conor Dooley 2025-09-02 4:24 ` [PATCH v2 3/4] riscv: Instroduce Zalasr instructions Xu Lu ` (2 subsequent siblings) 4 siblings, 1 reply; 18+ messages in thread From: Xu Lu @ 2025-09-02 4:24 UTC (permalink / raw) To: robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs Cc: devicetree, linux-riscv, linux-kernel, apw, joe, Xu Lu Add description for the Zalasr ISA extension Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> --- Documentation/devicetree/bindings/riscv/extensions.yaml | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml index ede6a58ccf534..100fe53fb0731 100644 --- a/Documentation/devicetree/bindings/riscv/extensions.yaml +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml @@ -242,6 +242,11 @@ properties: is supported as ratified at commit 5059e0ca641c ("update to ratified") of the riscv-zacas. + - const: zalasr + description: | + The standard Zalasr extension for load-acquire/store-release as frozen + at commit 194f0094 ("Version 0.9 for freeze") of riscv-zalasr. + - const: zalrsc description: | The standard Zalrsc extension for load-reserved/store-conditional as -- 2.20.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH v2 2/4] dt-bindings: riscv: Add Zalasr ISA extension description 2025-09-02 4:24 ` [PATCH v2 2/4] dt-bindings: riscv: Add Zalasr ISA extension description Xu Lu @ 2025-09-02 19:46 ` Conor Dooley 0 siblings, 0 replies; 18+ messages in thread From: Conor Dooley @ 2025-09-02 19:46 UTC (permalink / raw) To: Xu Lu Cc: robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe [-- Attachment #1: Type: text/plain, Size: 215 bytes --] On Tue, Sep 02, 2025 at 12:24:30PM +0800, Xu Lu wrote: > Add description for the Zalasr ISA extension > > Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 228 bytes --] ^ permalink raw reply [flat|nested] 18+ messages in thread
* [PATCH v2 3/4] riscv: Instroduce Zalasr instructions 2025-09-02 4:24 [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Xu Lu 2025-09-02 4:24 ` [PATCH v2 1/4] riscv: add ISA extension parsing for Zalasr Xu Lu 2025-09-02 4:24 ` [PATCH v2 2/4] dt-bindings: riscv: Add Zalasr ISA extension description Xu Lu @ 2025-09-02 4:24 ` Xu Lu 2025-09-02 4:24 ` [PATCH v2 4/4] riscv: Use Zalasr for smp_load_acquire/smp_store_release Xu Lu 2025-09-02 16:59 ` [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Andrea Parri 4 siblings, 0 replies; 18+ messages in thread From: Xu Lu @ 2025-09-02 4:24 UTC (permalink / raw) To: robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs Cc: devicetree, linux-riscv, linux-kernel, apw, joe, Xu Lu Introduce l{b|h|w|d}.{aq|aqrl} and s{b|h|w|d}.{rl|aqrl} instruction encodings. Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> --- arch/riscv/include/asm/insn-def.h | 79 +++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) diff --git a/arch/riscv/include/asm/insn-def.h b/arch/riscv/include/asm/insn-def.h index d5adbaec1d010..3fec7e66ce50f 100644 --- a/arch/riscv/include/asm/insn-def.h +++ b/arch/riscv/include/asm/insn-def.h @@ -179,6 +179,7 @@ #define RV___RS1(v) __RV_REG(v) #define RV___RS2(v) __RV_REG(v) +#define RV_OPCODE_AMO RV_OPCODE(47) #define RV_OPCODE_MISC_MEM RV_OPCODE(15) #define RV_OPCODE_OP_IMM RV_OPCODE(19) #define RV_OPCODE_SYSTEM RV_OPCODE(115) @@ -208,6 +209,84 @@ __ASM_STR(.error "hlv.d requires 64-bit support") #endif +#define LB_AQ(dest, addr) \ + INSN_R(OPCODE_AMO, FUNC3(0), FUNC7(26), \ + RD(dest), RS1(addr), __RS2(0)) + +#define LB_AQRL(dest, addr) \ + INSN_R(OPCODE_AMO, FUNC3(0), FUNC7(27), \ + RD(dest), RS1(addr), __RS2(0)) + +#define LH_AQ(dest, addr) \ + INSN_R(OPCODE_AMO, FUNC3(1), FUNC7(26), \ + RD(dest), RS1(addr), __RS2(0)) + +#define LH_AQRL(dest, addr) \ + INSN_R(OPCODE_AMO, FUNC3(1), FUNC7(27), \ + RD(dest), RS1(addr), __RS2(0)) + +#define LW_AQ(dest, addr) \ + INSN_R(OPCODE_AMO, FUNC3(2), FUNC7(26), \ + RD(dest), RS1(addr), __RS2(0)) + +#define LW_AQRL(dest, addr) \ + INSN_R(OPCODE_AMO, FUNC3(2), FUNC7(27), \ + RD(dest), RS1(addr), __RS2(0)) + +#define SB_RL(src, addr) \ + INSN_R(OPCODE_AMO, FUNC3(0), FUNC7(29), \ + __RD(0), RS1(addr), RS2(src)) + +#define SB_AQRL(src, addr) \ + INSN_R(OPCODE_AMO, FUNC3(0), FUNC7(31), \ + __RD(0), RS1(addr), RS2(src)) + +#define SH_RL(src, addr) \ + INSN_R(OPCODE_AMO, FUNC3(1), FUNC7(29), \ + __RD(0), RS1(addr), RS2(src)) + +#define SH_AQRL(src, addr) \ + INSN_R(OPCODE_AMO, FUNC3(1), FUNC7(31), \ + __RD(0), RS1(addr), RS2(src)) + +#define SW_RL(src, addr) \ + INSN_R(OPCODE_AMO, FUNC3(2), FUNC7(29), \ + __RD(0), RS1(addr), RS2(src)) + +#define SW_AQRL(src, addr) \ + INSN_R(OPCODE_AMO, FUNC3(2), FUNC7(31), \ + __RD(0), RS1(addr), RS2(src)) + +#ifdef CONFIG_64BIT +#define LD_AQ(dest, addr) \ + INSN_R(OPCODE_AMO, FUNC3(3), FUNC7(26), \ + RD(dest), RS1(addr), __RS2(0)) + +#define LD_AQRL(dest, addr) \ + INSN_R(OPCODE_AMO, FUNC3(3), FUNC7(27), \ + RD(dest), RS1(addr), __RS2(0)) + +#define SD_RL(src, addr) \ + INSN_R(OPCODE_AMO, FUNC3(3), FUNC7(29), \ + __RD(0), RS1(addr), RS2(src)) + +#define SD_AQRL(src, addr) \ + INSN_R(OPCODE_AMO, FUNC3(3), FUNC7(31), \ + __RD(0), RS1(addr), RS2(src)) +#else +#define LD_AQ(dest, addr) \ + __ASM_STR(.error "ld.aq requires 64-bit support") + +#define LD_AQRL(dest, addr) \ + __ASM_STR(.error "ld.aqrl requires 64-bit support") + +#define SD_RL(dest, addr) \ + __ASM_STR(.error "sd.rl requires 64-bit support") + +#define SD_AQRL(dest, addr) \ + __ASM_STR(.error "sd.aqrl requires 64-bit support") +#endif + #define SINVAL_VMA(vaddr, asid) \ INSN_R(OPCODE_SYSTEM, FUNC3(0), FUNC7(11), \ __RD(0), RS1(vaddr), RS2(asid)) -- 2.20.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [PATCH v2 4/4] riscv: Use Zalasr for smp_load_acquire/smp_store_release 2025-09-02 4:24 [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Xu Lu ` (2 preceding siblings ...) 2025-09-02 4:24 ` [PATCH v2 3/4] riscv: Instroduce Zalasr instructions Xu Lu @ 2025-09-02 4:24 ` Xu Lu 2025-09-03 1:06 ` kernel test robot 2025-09-02 16:59 ` [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Andrea Parri 4 siblings, 1 reply; 18+ messages in thread From: Xu Lu @ 2025-09-02 4:24 UTC (permalink / raw) To: robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs Cc: devicetree, linux-riscv, linux-kernel, apw, joe, Xu Lu Replace fence instructions with Zalasr instructions during acquire or release operations. Signed-off-by: Xu Lu <luxu.kernel@bytedance.com> --- arch/riscv/include/asm/barrier.h | 79 +++++++++++++++++++++++++++----- 1 file changed, 68 insertions(+), 11 deletions(-) diff --git a/arch/riscv/include/asm/barrier.h b/arch/riscv/include/asm/barrier.h index b8c5726d86acb..b1d2a9a85256d 100644 --- a/arch/riscv/include/asm/barrier.h +++ b/arch/riscv/include/asm/barrier.h @@ -51,19 +51,76 @@ */ #define smp_mb__after_spinlock() RISCV_FENCE(iorw, iorw) -#define __smp_store_release(p, v) \ -do { \ - compiletime_assert_atomic_type(*p); \ - RISCV_FENCE(rw, w); \ - WRITE_ONCE(*p, v); \ +extern void __bad_size_call_parameter(void); + +#define __smp_store_release(p, v) \ +do { \ + compiletime_assert_atomic_type(*p); \ + switch (sizeof(*p)) { \ + case 1: \ + asm volatile(ALTERNATIVE("fence rw, w;\t\nsb %0, 0(%1)\t\n", \ + SB_RL(%0, %1) "\t\nnop\t\n", \ + 0, RISCV_ISA_EXT_ZALASR, 1) \ + : : "r" (v), "r" (p) : "memory"); \ + break; \ + case 2: \ + asm volatile(ALTERNATIVE("fence rw, w;\t\nsh %0, 0(%1)\t\n", \ + SH_RL(%0, %1) "\t\nnop\t\n", \ + 0, RISCV_ISA_EXT_ZALASR, 1) \ + : : "r" (v), "r" (p) : "memory"); \ + break; \ + case 4: \ + asm volatile(ALTERNATIVE("fence rw, w;\t\nsw %0, 0(%1)\t\n", \ + SW_RL(%0, %1) "\t\nnop\t\n", \ + 0, RISCV_ISA_EXT_ZALASR, 1) \ + : : "r" (v), "r" (p) : "memory"); \ + break; \ + case 8: \ + asm volatile(ALTERNATIVE("fence rw, w;\t\nsd %0, 0(%1)\t\n", \ + SD_RL(%0, %1) "\t\nnop\t\n", \ + 0, RISCV_ISA_EXT_ZALASR, 1) \ + : : "r" (v), "r" (p) : "memory"); \ + break; \ + default: \ + __bad_size_call_parameter(); \ + break; \ + } \ } while (0) -#define __smp_load_acquire(p) \ -({ \ - typeof(*p) ___p1 = READ_ONCE(*p); \ - compiletime_assert_atomic_type(*p); \ - RISCV_FENCE(r, rw); \ - ___p1; \ +#define __smp_load_acquire(p) \ +({ \ + TYPEOF_UNQUAL(*p) val; \ + compiletime_assert_atomic_type(*p); \ + switch (sizeof(*p)) { \ + case 1: \ + asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ + LB_AQ(%0, %1) "\t\nnop\t\n", \ + 0, RISCV_ISA_EXT_ZALASR, 1) \ + : "=r" (val) : "r" (p) : "memory"); \ + break; \ + case 2: \ + asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ + LH_AQ(%0, %1) "\t\nnop\t\n", \ + 0, RISCV_ISA_EXT_ZALASR, 1) \ + : "=r" (val) : "r" (p) : "memory"); \ + break; \ + case 4: \ + asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ + LW_AQ(%0, %1) "\t\nnop\t\n", \ + 0, RISCV_ISA_EXT_ZALASR, 1) \ + : "=r" (val) : "r" (p) : "memory"); \ + break; \ + case 8: \ + asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ + LD_AQ(%0, %1) "\t\nnop\t\n", \ + 0, RISCV_ISA_EXT_ZALASR, 1) \ + : "=r" (val) : "r" (p) : "memory"); \ + break; \ + default: \ + __bad_size_call_parameter(); \ + break; \ + } \ + val; \ }) #ifdef CONFIG_RISCV_ISA_ZAWRS -- 2.20.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [PATCH v2 4/4] riscv: Use Zalasr for smp_load_acquire/smp_store_release 2025-09-02 4:24 ` [PATCH v2 4/4] riscv: Use Zalasr for smp_load_acquire/smp_store_release Xu Lu @ 2025-09-03 1:06 ` kernel test robot 0 siblings, 0 replies; 18+ messages in thread From: kernel test robot @ 2025-09-03 1:06 UTC (permalink / raw) To: Xu Lu, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs Cc: oe-kbuild-all, devicetree, linux-riscv, linux-kernel, apw, joe, Xu Lu Hi Xu, kernel test robot noticed the following build errors: [auto build test ERROR on robh/for-next] [also build test ERROR on linus/master v6.17-rc4 next-20250902] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Xu-Lu/riscv-add-ISA-extension-parsing-for-Zalasr/20250902-123357 base: https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next patch link: https://lore.kernel.org/r/20250902042432.78960-5-luxu.kernel%40bytedance.com patch subject: [PATCH v2 4/4] riscv: Use Zalasr for smp_load_acquire/smp_store_release config: riscv-randconfig-002-20250903 (https://download.01.org/0day-ci/archive/20250903/202509030832.0uHQ24ec-lkp@intel.com/config) compiler: riscv64-linux-gcc (GCC) 9.5.0 reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20250903/202509030832.0uHQ24ec-lkp@intel.com/reproduce) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp@intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202509030832.0uHQ24ec-lkp@intel.com/ All errors (new ones prefixed by >>): In file included from include/asm-generic/bitops/generic-non-atomic.h:7, from include/linux/bitops.h:28, from include/linux/thread_info.h:27, from include/asm-generic/preempt.h:5, from ./arch/riscv/include/generated/asm/preempt.h:1, from include/linux/preempt.h:79, from include/linux/spinlock.h:56, from include/linux/mmzone.h:8, from include/linux/gfp.h:7, from include/linux/mm.h:7, from arch/riscv/kernel/asm-offsets.c:8: include/linux/list.h: In function 'list_empty_careful': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/list.h:409:27: note: in expansion of macro 'smp_load_acquire' 409 | struct list_head *next = smp_load_acquire(&head->next); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/list.h:409:27: note: in expansion of macro 'smp_load_acquire' 409 | struct list_head *next = smp_load_acquire(&head->next); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/list.h:409:27: note: in expansion of macro 'smp_load_acquire' 409 | struct list_head *next = smp_load_acquire(&head->next); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/list.h:409:27: note: in expansion of macro 'smp_load_acquire' 409 | struct list_head *next = smp_load_acquire(&head->next); | ^~~~~~~~~~~~~~~~ In file included from include/asm-generic/bitops/generic-non-atomic.h:7, from include/linux/bitops.h:28, from include/linux/thread_info.h:27, from include/asm-generic/preempt.h:5, from ./arch/riscv/include/generated/asm/preempt.h:1, from include/linux/preempt.h:79, from include/linux/spinlock.h:56, from include/linux/mmzone.h:8, from include/linux/gfp.h:7, from include/linux/mm.h:7, from arch/riscv/kernel/asm-offsets.c:8: include/linux/atomic/atomic-arch-fallback.h: In function 'raw_atomic_read_acquire': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h:479:9: note: in expansion of macro 'smp_load_acquire' 479 | ret = smp_load_acquire(&(v)->counter); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h:479:9: note: in expansion of macro 'smp_load_acquire' 479 | ret = smp_load_acquire(&(v)->counter); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h:479:9: note: in expansion of macro 'smp_load_acquire' 479 | ret = smp_load_acquire(&(v)->counter); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h:479:9: note: in expansion of macro 'smp_load_acquire' 479 | ret = smp_load_acquire(&(v)->counter); | ^~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h: In function 'raw_atomic64_read_acquire': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h:2605:9: note: in expansion of macro 'smp_load_acquire' 2605 | ret = smp_load_acquire(&(v)->counter); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h:2605:9: note: in expansion of macro 'smp_load_acquire' 2605 | ret = smp_load_acquire(&(v)->counter); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h:2605:9: note: in expansion of macro 'smp_load_acquire' 2605 | ret = smp_load_acquire(&(v)->counter); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/atomic/atomic-arch-fallback.h:2605:9: note: in expansion of macro 'smp_load_acquire' 2605 | ret = smp_load_acquire(&(v)->counter); | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h: In function '__seqprop_sequence': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:211:9: note: in expansion of macro 'smp_load_acquire' 211 | return smp_load_acquire(&s->sequence); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:211:9: note: in expansion of macro 'smp_load_acquire' 211 | return smp_load_acquire(&s->sequence); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:211:9: note: in expansion of macro 'smp_load_acquire' 211 | return smp_load_acquire(&s->sequence); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:211:9: note: in expansion of macro 'smp_load_acquire' 211 | return smp_load_acquire(&s->sequence); | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h: In function '__seqprop_raw_spinlock_sequence': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:226:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 226 | SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t, false, raw_spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:226:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 226 | SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t, false, raw_spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:226:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 226 | SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t, false, raw_spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:226:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 226 | SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t, false, raw_spin) | ^~~~~~~~~~~~~~~~~ >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:226:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 226 | SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t, false, raw_spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:226:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 226 | SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t, false, raw_spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:226:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 226 | SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t, false, raw_spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:226:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 226 | SEQCOUNT_LOCKNAME(raw_spinlock, raw_spinlock_t, false, raw_spin) | ^~~~~~~~~~~~~~~~~ include/linux/seqlock.h: In function '__seqprop_spinlock_sequence': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:227:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 227 | SEQCOUNT_LOCKNAME(spinlock, spinlock_t, __SEQ_RT, spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:227:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 227 | SEQCOUNT_LOCKNAME(spinlock, spinlock_t, __SEQ_RT, spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:227:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 227 | SEQCOUNT_LOCKNAME(spinlock, spinlock_t, __SEQ_RT, spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:227:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 227 | SEQCOUNT_LOCKNAME(spinlock, spinlock_t, __SEQ_RT, spin) | ^~~~~~~~~~~~~~~~~ >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:227:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 227 | SEQCOUNT_LOCKNAME(spinlock, spinlock_t, __SEQ_RT, spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:227:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 227 | SEQCOUNT_LOCKNAME(spinlock, spinlock_t, __SEQ_RT, spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:227:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 227 | SEQCOUNT_LOCKNAME(spinlock, spinlock_t, __SEQ_RT, spin) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:227:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 227 | SEQCOUNT_LOCKNAME(spinlock, spinlock_t, __SEQ_RT, spin) | ^~~~~~~~~~~~~~~~~ include/linux/seqlock.h: In function '__seqprop_rwlock_sequence': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:228:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 228 | SEQCOUNT_LOCKNAME(rwlock, rwlock_t, __SEQ_RT, read) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:228:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 228 | SEQCOUNT_LOCKNAME(rwlock, rwlock_t, __SEQ_RT, read) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:228:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 228 | SEQCOUNT_LOCKNAME(rwlock, rwlock_t, __SEQ_RT, read) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:228:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 228 | SEQCOUNT_LOCKNAME(rwlock, rwlock_t, __SEQ_RT, read) | ^~~~~~~~~~~~~~~~~ >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:228:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 228 | SEQCOUNT_LOCKNAME(rwlock, rwlock_t, __SEQ_RT, read) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:228:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 228 | SEQCOUNT_LOCKNAME(rwlock, rwlock_t, __SEQ_RT, read) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:228:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 228 | SEQCOUNT_LOCKNAME(rwlock, rwlock_t, __SEQ_RT, read) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:228:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 228 | SEQCOUNT_LOCKNAME(rwlock, rwlock_t, __SEQ_RT, read) | ^~~~~~~~~~~~~~~~~ include/linux/seqlock.h: In function '__seqprop_mutex_sequence': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:229:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 229 | SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:229:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 229 | SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:229:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 229 | SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:160:17: note: in expansion of macro 'smp_load_acquire' 160 | unsigned seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:229:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 229 | SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex) | ^~~~~~~~~~~~~~~~~ >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:229:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 229 | SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:229:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 229 | SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:229:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 229 | SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex) | ^~~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/seqlock.h:173:9: note: in expansion of macro 'smp_load_acquire' 173 | seq = smp_load_acquire(&s->seqcount.sequence); \ | ^~~~~~~~~~~~~~~~ include/linux/seqlock.h:229:1: note: in expansion of macro 'SEQCOUNT_LOCKNAME' 229 | SEQCOUNT_LOCKNAME(mutex, struct mutex, true, mutex) | ^~~~~~~~~~~~~~~~~ In file included from include/asm-generic/bitops/generic-non-atomic.h:7, from include/linux/bitops.h:28, from include/linux/thread_info.h:27, from include/asm-generic/preempt.h:5, from ./arch/riscv/include/generated/asm/preempt.h:1, from include/linux/preempt.h:79, from include/linux/spinlock.h:56, from include/linux/mmzone.h:8, from include/linux/gfp.h:7, from include/linux/mm.h:7, from arch/riscv/kernel/asm-offsets.c:8: include/linux/key.h: In function 'key_read_state': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/key.h:459:9: note: in expansion of macro 'smp_load_acquire' 459 | return smp_load_acquire(&key->state); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/key.h:459:9: note: in expansion of macro 'smp_load_acquire' 459 | return smp_load_acquire(&key->state); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/key.h:459:9: note: in expansion of macro 'smp_load_acquire' 459 | return smp_load_acquire(&key->state); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/key.h:459:9: note: in expansion of macro 'smp_load_acquire' 459 | return smp_load_acquire(&key->state); | ^~~~~~~~~~~~~~~~ include/linux/fs.h: In function 'i_size_read': >> arch/riscv/include/asm/barrier.h:96:3: error: read-only variable 'val' used as 'asm' output 96 | asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/fs.h:988:9: note: in expansion of macro 'smp_load_acquire' 988 | return smp_load_acquire(&inode->i_size); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:102:3: error: read-only variable 'val' used as 'asm' output 102 | asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/fs.h:988:9: note: in expansion of macro 'smp_load_acquire' 988 | return smp_load_acquire(&inode->i_size); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:108:3: error: read-only variable 'val' used as 'asm' output 108 | asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/fs.h:988:9: note: in expansion of macro 'smp_load_acquire' 988 | return smp_load_acquire(&inode->i_size); | ^~~~~~~~~~~~~~~~ arch/riscv/include/asm/barrier.h:114:3: error: read-only variable 'val' used as 'asm' output 114 | asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ | ^~~ include/asm-generic/barrier.h:176:29: note: in expansion of macro '__smp_load_acquire' 176 | #define smp_load_acquire(p) __smp_load_acquire(p) | ^~~~~~~~~~~~~~~~~~ include/linux/fs.h:988:9: note: in expansion of macro 'smp_load_acquire' 988 | return smp_load_acquire(&inode->i_size); | ^~~~~~~~~~~~~~~~ make[3]: *** [scripts/Makefile.build:182: arch/riscv/kernel/asm-offsets.s] Error 1 shuffle=1073380763 make[3]: Target 'prepare' not remade because of errors. make[2]: *** [Makefile:1282: prepare0] Error 2 shuffle=1073380763 make[2]: Target 'prepare' not remade because of errors. make[1]: *** [Makefile:248: __sub-make] Error 2 shuffle=1073380763 make[1]: Target 'prepare' not remade because of errors. make: *** [Makefile:248: __sub-make] Error 2 shuffle=1073380763 make: Target 'prepare' not remade because of errors. vim +96 arch/riscv/include/asm/barrier.h 89 90 #define __smp_load_acquire(p) \ 91 ({ \ 92 TYPEOF_UNQUAL(*p) val; \ 93 compiletime_assert_atomic_type(*p); \ 94 switch (sizeof(*p)) { \ 95 case 1: \ > 96 asm volatile(ALTERNATIVE("lb %0, 0(%1)\t\nfence r, rw\t\n", \ 97 LB_AQ(%0, %1) "\t\nnop\t\n", \ 98 0, RISCV_ISA_EXT_ZALASR, 1) \ 99 : "=r" (val) : "r" (p) : "memory"); \ 100 break; \ 101 case 2: \ 102 asm volatile(ALTERNATIVE("lh %0, 0(%1)\t\nfence r, rw\t\n", \ 103 LH_AQ(%0, %1) "\t\nnop\t\n", \ 104 0, RISCV_ISA_EXT_ZALASR, 1) \ 105 : "=r" (val) : "r" (p) : "memory"); \ 106 break; \ 107 case 4: \ 108 asm volatile(ALTERNATIVE("lw %0, 0(%1)\t\nfence r, rw\t\n", \ 109 LW_AQ(%0, %1) "\t\nnop\t\n", \ 110 0, RISCV_ISA_EXT_ZALASR, 1) \ 111 : "=r" (val) : "r" (p) : "memory"); \ 112 break; \ 113 case 8: \ 114 asm volatile(ALTERNATIVE("ld %0, 0(%1)\t\nfence r, rw\t\n", \ 115 LD_AQ(%0, %1) "\t\nnop\t\n", \ 116 0, RISCV_ISA_EXT_ZALASR, 1) \ 117 : "=r" (val) : "r" (p) : "memory"); \ 118 break; \ 119 default: \ 120 __bad_size_call_parameter(); \ 121 break; \ 122 } \ 123 val; \ 124 }) 125 -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-02 4:24 [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Xu Lu ` (3 preceding siblings ...) 2025-09-02 4:24 ` [PATCH v2 4/4] riscv: Use Zalasr for smp_load_acquire/smp_store_release Xu Lu @ 2025-09-02 16:59 ` Andrea Parri 2025-09-03 11:41 ` [External] " Xu Lu 2025-09-17 4:01 ` Guo Ren 4 siblings, 2 replies; 18+ messages in thread From: Andrea Parri @ 2025-09-02 16:59 UTC (permalink / raw) To: Xu Lu Cc: robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe > Xu Lu (4): > riscv: add ISA extension parsing for Zalasr > dt-bindings: riscv: Add Zalasr ISA extension description > riscv: Instroduce Zalasr instructions > riscv: Use Zalasr for smp_load_acquire/smp_store_release Informally put, our (Linux) memory consistency model specifies that any sequence spin_unlock(s); spin_lock(t); behaves "as it provides at least FENCE.TSO ordering between operations which precede the UNLOCK+LOCK sequence and operations which follow the sequence". Unless I missing something, the patch set in question breaks such ordering property (on RISC-V): for example, a "release" annotation, .RL (as in spin_unlock() -> smp_store_release(), after patch #4) paired with an "acquire" fence, FENCE R,RW (as could be found in spin_lock() -> atomic_try_cmpxchg_acquire()) do not provide the specified property. I _think some solutions to the issue above include: a) make sure an .RL annotation is always paired with an .AQ annotation and viceversa an .AQ annotation is paired with an .RL annotation (this approach matches the current arm64 approach/implementation); b) on the opposite direction, always pair FENCE R,RW (or occasionally FENCE R,R) with FENCE RW,W (this matches the current approach/the current implementation within riscv); c) mix the previous two solutions (resp., annotations and fences), but make sure to "upgrade" any releases to provide (insert) a FENCE.TSO. (a) would align RISC-V and ARM64 (which is a good thing IMO), though it is probably the most invasive approach among the three approaches above (requiring certain changes to arch/riscv/include/asm/{cmpxchg,atomic}.h, which are already relatively messy due to the various ZABHA plus ZACAS switches). Overall, I'm not too exited at the idea of reviewing any of those changes, but if the community opts for it, I'll almost definitely take a closer look with due calm. ;-) Andrea ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [External] Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-02 16:59 ` [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Andrea Parri @ 2025-09-03 11:41 ` Xu Lu 2025-09-17 4:01 ` Guo Ren 1 sibling, 0 replies; 18+ messages in thread From: Xu Lu @ 2025-09-03 11:41 UTC (permalink / raw) To: Andrea Parri Cc: robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe Hi Andrea, Great catch! Thanks a lot for your review. The problem comes from the mixed use of acquire/release semantics via fence and via real ld.aq/sd.rl. I would prefer your method (a). The existing atomic acquire/release functions' implementation can be further modified to amocas.sq/amocas.rl/lr.aq/sc.rl. I will send the next version after I finish it and hope you can help with review then. Best regards, Xu Lu On Wed, Sep 3, 2025 at 12:59 AM Andrea Parri <parri.andrea@gmail.com> wrote: > > > Xu Lu (4): > > riscv: add ISA extension parsing for Zalasr > > dt-bindings: riscv: Add Zalasr ISA extension description > > riscv: Instroduce Zalasr instructions > > riscv: Use Zalasr for smp_load_acquire/smp_store_release > > Informally put, our (Linux) memory consistency model specifies that any > sequence > > spin_unlock(s); > spin_lock(t); > > behaves "as it provides at least FENCE.TSO ordering between operations > which precede the UNLOCK+LOCK sequence and operations which follow the > sequence". Unless I missing something, the patch set in question breaks > such ordering property (on RISC-V): for example, a "release" annotation, > .RL (as in spin_unlock() -> smp_store_release(), after patch #4) paired > with an "acquire" fence, FENCE R,RW (as could be found in spin_lock() -> > atomic_try_cmpxchg_acquire()) do not provide the specified property. > > I _think some solutions to the issue above include: > > a) make sure an .RL annotation is always paired with an .AQ annotation > and viceversa an .AQ annotation is paired with an .RL annotation > (this approach matches the current arm64 approach/implementation); > > b) on the opposite direction, always pair FENCE R,RW (or occasionally > FENCE R,R) with FENCE RW,W (this matches the current approach/the > current implementation within riscv); > > c) mix the previous two solutions (resp., annotations and fences), but > make sure to "upgrade" any releases to provide (insert) a FENCE.TSO. > > (a) would align RISC-V and ARM64 (which is a good thing IMO), though it > is probably the most invasive approach among the three approaches above > (requiring certain changes to arch/riscv/include/asm/{cmpxchg,atomic}.h, > which are already relatively messy due to the various ZABHA plus ZACAS > switches). Overall, I'm not too exited at the idea of reviewing any of > those changes, but if the community opts for it, I'll almost definitely > take a closer look with due calm. ;-) > > Andrea ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-02 16:59 ` [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Andrea Parri 2025-09-03 11:41 ` [External] " Xu Lu @ 2025-09-17 4:01 ` Guo Ren 2025-09-17 4:57 ` Guo Ren 2025-09-18 16:48 ` Guo Ren 1 sibling, 2 replies; 18+ messages in thread From: Guo Ren @ 2025-09-17 4:01 UTC (permalink / raw) To: Andrea Parri Cc: Xu Lu, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe On Tue, Sep 02, 2025 at 06:59:15PM +0200, Andrea Parri wrote: > > Xu Lu (4): > > riscv: add ISA extension parsing for Zalasr > > dt-bindings: riscv: Add Zalasr ISA extension description > > riscv: Instroduce Zalasr instructions > > riscv: Use Zalasr for smp_load_acquire/smp_store_release > > Informally put, our (Linux) memory consistency model specifies that any > sequence > > spin_unlock(s); > spin_lock(t); > > behaves "as it provides at least FENCE.TSO ordering between operations > which precede the UNLOCK+LOCK sequence and operations which follow the > sequence". Unless I missing something, the patch set in question breaks > such ordering property (on RISC-V): for example, a "release" annotation, > .RL (as in spin_unlock() -> smp_store_release(), after patch #4) paired > with an "acquire" fence, FENCE R,RW (as could be found in spin_lock() -> > atomic_try_cmpxchg_acquire()) do not provide the specified property. > > I _think some solutions to the issue above include: > > a) make sure an .RL annotation is always paired with an .AQ annotation > and viceversa an .AQ annotation is paired with an .RL annotation > (this approach matches the current arm64 approach/implementation); > > b) on the opposite direction, always pair FENCE R,RW (or occasionally > FENCE R,R) with FENCE RW,W (this matches the current approach/the > current implementation within riscv); > > c) mix the previous two solutions (resp., annotations and fences), but > make sure to "upgrade" any releases to provide (insert) a FENCE.TSO. I prefer option c) at first, it has fewer modification and influence. asm volatile(ALTERNATIVE("fence rw, w;\t\nsb %0, 0(%1)\t\n", \ - SB_RL(%0, %1) "\t\nnop\t\n", \ + SB_RL(%0, %1) "\t\n fence.tso;\t\n", \ 0, RISCV_ISA_EXT_ZALASR, 1) \ : : "r" (v), "r" (p) : "memory"); \ I didn't object option a), and I think it could be done in the future. Acquire Zalasr extension step by step. > > (a) would align RISC-V and ARM64 (which is a good thing IMO), though it > is probably the most invasive approach among the three approaches above > (requiring certain changes to arch/riscv/include/asm/{cmpxchg,atomic}.h, > which are already relatively messy due to the various ZABHA plus ZACAS > switches). Overall, I'm not too exited at the idea of reviewing any of > those changes, but if the community opts for it, I'll almost definitely > take a closer look with due calm. ;-) > > Andrea > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-17 4:01 ` Guo Ren @ 2025-09-17 4:57 ` Guo Ren 2025-09-18 16:48 ` Guo Ren 1 sibling, 0 replies; 18+ messages in thread From: Guo Ren @ 2025-09-17 4:57 UTC (permalink / raw) To: Andrea Parri Cc: Xu Lu, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe On Wed, Sep 17, 2025 at 12:01:34AM -0400, Guo Ren wrote: > On Tue, Sep 02, 2025 at 06:59:15PM +0200, Andrea Parri wrote: > > > Xu Lu (4): > > > riscv: add ISA extension parsing for Zalasr > > > dt-bindings: riscv: Add Zalasr ISA extension description > > > riscv: Instroduce Zalasr instructions > > > riscv: Use Zalasr for smp_load_acquire/smp_store_release > > > > Informally put, our (Linux) memory consistency model specifies that any > > sequence > > > > spin_unlock(s); > > spin_lock(t); > > > > behaves "as it provides at least FENCE.TSO ordering between operations > > which precede the UNLOCK+LOCK sequence and operations which follow the > > sequence". Unless I missing something, the patch set in question breaks > > such ordering property (on RISC-V): for example, a "release" annotation, > > .RL (as in spin_unlock() -> smp_store_release(), after patch #4) paired > > with an "acquire" fence, FENCE R,RW (as could be found in spin_lock() -> > > atomic_try_cmpxchg_acquire()) do not provide the specified property. > > > > I _think some solutions to the issue above include: > > > > a) make sure an .RL annotation is always paired with an .AQ annotation > > and viceversa an .AQ annotation is paired with an .RL annotation > > (this approach matches the current arm64 approach/implementation); > > > > b) on the opposite direction, always pair FENCE R,RW (or occasionally > > FENCE R,R) with FENCE RW,W (this matches the current approach/the > > current implementation within riscv); > > > > c) mix the previous two solutions (resp., annotations and fences), but > > make sure to "upgrade" any releases to provide (insert) a FENCE.TSO. > I prefer option c) at first, it has fewer modification and influence. > > asm volatile(ALTERNATIVE("fence rw, w;\t\nsb %0, 0(%1)\t\n", \ > - SB_RL(%0, %1) "\t\nnop\t\n", \ > + SB_RL(%0, %1) "\t\n fence.tso;\t\n", \ "fence rw, rw;\t\nsb %0, 0(%1)\t\n", \ How about enhance fence rw, rw? It's a bit more stronger than .tso. 0, RISCV_ISA_EXT_ZALASR, 1) \ > : : "r" (v), "r" (p) : "memory"); \ > > I didn't object option a), and I think it could be done in the future. > Acquire Zalasr extension step by step. > > > > > (a) would align RISC-V and ARM64 (which is a good thing IMO), though it > > is probably the most invasive approach among the three approaches above > > (requiring certain changes to arch/riscv/include/asm/{cmpxchg,atomic}.h, > > which are already relatively messy due to the various ZABHA plus ZACAS > > switches). Overall, I'm not too exited at the idea of reviewing any of > > those changes, but if the community opts for it, I'll almost definitely > > take a closer look with due calm. ;-) > > > > Andrea > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-17 4:01 ` Guo Ren 2025-09-17 4:57 ` Guo Ren @ 2025-09-18 16:48 ` Guo Ren 2025-09-18 21:24 ` Andrea Parri 2025-09-19 3:18 ` [External] " Xu Lu 1 sibling, 2 replies; 18+ messages in thread From: Guo Ren @ 2025-09-18 16:48 UTC (permalink / raw) To: Andrea Parri Cc: Xu Lu, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe On Wed, Sep 17, 2025 at 12:01:34AM -0400, Guo Ren wrote: > On Tue, Sep 02, 2025 at 06:59:15PM +0200, Andrea Parri wrote: > > > Xu Lu (4): > > > riscv: add ISA extension parsing for Zalasr > > > dt-bindings: riscv: Add Zalasr ISA extension description > > > riscv: Instroduce Zalasr instructions > > > riscv: Use Zalasr for smp_load_acquire/smp_store_release > > > > Informally put, our (Linux) memory consistency model specifies that any > > sequence > > > > spin_unlock(s); > > spin_lock(t); > > > > behaves "as it provides at least FENCE.TSO ordering between operations > > which precede the UNLOCK+LOCK sequence and operations which follow the > > sequence". Unless I missing something, the patch set in question breaks > > such ordering property (on RISC-V): for example, a "release" annotation, > > .RL (as in spin_unlock() -> smp_store_release(), after patch #4) paired > > with an "acquire" fence, FENCE R,RW (as could be found in spin_lock() -> > > atomic_try_cmpxchg_acquire()) do not provide the specified property. > > > > I _think some solutions to the issue above include: > > > > a) make sure an .RL annotation is always paired with an .AQ annotation > > and viceversa an .AQ annotation is paired with an .RL annotation > > (this approach matches the current arm64 approach/implementation); > > > > b) on the opposite direction, always pair FENCE R,RW (or occasionally > > FENCE R,R) with FENCE RW,W (this matches the current approach/the > > current implementation within riscv); > > > > c) mix the previous two solutions (resp., annotations and fences), but > > make sure to "upgrade" any releases to provide (insert) a FENCE.TSO. > I prefer option c) at first, it has fewer modification and influence. Another reason is that store-release-to-load-acquire would give out a FENCE rw, rw according to RVWMO PPO 7th rule instead of FENCE.TSO, which is stricter than the Linux requirement you've mentioned. > > asm volatile(ALTERNATIVE("fence rw, w;\t\nsb %0, 0(%1)\t\n", \ > - SB_RL(%0, %1) "\t\nnop\t\n", \ > + SB_RL(%0, %1) "\t\n fence.tso;\t\n", \ > 0, RISCV_ISA_EXT_ZALASR, 1) \ > : : "r" (v), "r" (p) : "memory"); \ > > I didn't object option a), and I think it could be done in the future. > Acquire Zalasr extension step by step. > > > > > (a) would align RISC-V and ARM64 (which is a good thing IMO), though it > > is probably the most invasive approach among the three approaches above > > (requiring certain changes to arch/riscv/include/asm/{cmpxchg,atomic}.h, > > which are already relatively messy due to the various ZABHA plus ZACAS > > switches). Overall, I'm not too exited at the idea of reviewing any of > > those changes, but if the community opts for it, I'll almost definitely > > take a closer look with due calm. ;-) > > > > Andrea > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-18 16:48 ` Guo Ren @ 2025-09-18 21:24 ` Andrea Parri 2025-09-20 5:59 ` Guo Ren 2025-09-19 3:18 ` [External] " Xu Lu 1 sibling, 1 reply; 18+ messages in thread From: Andrea Parri @ 2025-09-18 21:24 UTC (permalink / raw) To: Guo Ren Cc: Xu Lu, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe [merging replies] > > I prefer option c) at first, it has fewer modification and influence. > Another reason is that store-release-to-load-acquire would give out a > FENCE rw, rw according to RVWMO PPO 7th rule instead of FENCE.TSO, which > is stricter than the Linux requirement you've mentioned. I mean, if "fewer modification" and "not-a-full-fence" were the only arguments, we would probably just stick with the current scheme (b), right? What other arguments are available? Don't get me wrong: no a priori objection from my end; I was really just wondering about the various interests/rationales in the RISC-V kernel community. (It may surprise you, but some communities did consider that "UNLOCK+LOCK is not a full memory barrier" a disadvantage, because briefly "locking should provide strong ordering guarantees and be easy to reason about"; in fact, not just "locking" if we consider x86 or arm64...) > > asm volatile(ALTERNATIVE("fence rw, w;\t\nsb %0, 0(%1)\t\n", \ > > - SB_RL(%0, %1) "\t\nnop\t\n", \ > > + SB_RL(%0, %1) "\t\n fence.tso;\t\n", \ > > 0, RISCV_ISA_EXT_ZALASR, 1) \ > > : : "r" (v), "r" (p) : "memory"); \ nit: Why placing the fence after the store? I imagine that FENCE.TSO could precede the store, this way, the store would actually not need to have that .RL annotation. More importantly, That for (part of) smp_store_release(). Let me stress that my option (c) was meant to include similar changes for _every releases (that is, cmpxchg_release(), atomic_inc_return_release(), and many other), even if most of such releases do not currently create "problematic pairs" with a corresponding acquire: the concern is that future changes in the RISC-V atomics implementation or in generic locking code will introduce pairs of the form FENCE RW,W + .AQ or .RL + FENCE R,RW without anyone noticing... In other words, I was suggesting that RISC-V _continues to meet the ordering property under discussion "by design" rather than "by Andrea or whoever's code auditing/review" (assuming it's feasible, i.e. that it doesn't clash with other people's arguments?); options (a) and (b) were also "designed" following this same criterion. Andrea ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-18 21:24 ` Andrea Parri @ 2025-09-20 5:59 ` Guo Ren 0 siblings, 0 replies; 18+ messages in thread From: Guo Ren @ 2025-09-20 5:59 UTC (permalink / raw) To: Andrea Parri Cc: Xu Lu, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe On Fri, Sep 19, 2025 at 5:24 AM Andrea Parri <parri.andrea@gmail.com> wrote: > > [merging replies] > > > > I prefer option c) at first, it has fewer modification and influence. > > Another reason is that store-release-to-load-acquire would give out a > > FENCE rw, rw according to RVWMO PPO 7th rule instead of FENCE.TSO, which > > is stricter than the Linux requirement you've mentioned. > > I mean, if "fewer modification" and "not-a-full-fence" were the only > arguments, we would probably just stick with the current scheme (b), > right? What other arguments are available? Don't get me wrong: no a > priori objection from my end; I was really just wondering about the > various interests/rationales in the RISC-V kernel community. (It may > surprise you, but some communities did consider that "UNLOCK+LOCK is > not a full memory barrier" a disadvantage, because briefly "locking > should provide strong ordering guarantees and be easy to reason about"; > in fact, not just "locking" if we consider x86 or arm64...) The ld.aq is really faster than the "ld + fence r, rw" in microarch. I don't care about the performance of the "UNLOCK+LOCK" scenario. > > > > > asm volatile(ALTERNATIVE("fence rw, w;\t\nsb %0, 0(%1)\t\n", \ > > > - SB_RL(%0, %1) "\t\nnop\t\n", \ > > > + SB_RL(%0, %1) "\t\n fence.tso;\t\n", \ > > > 0, RISCV_ISA_EXT_ZALASR, 1) \ > > > : : "r" (v), "r" (p) : "memory"); \ > > nit: Why placing the fence after the store? I imagine that FENCE.TSO > could precede the store, this way, the store would actually not need > to have that .RL annotation. More importantly, Yes, fence.tso is stricter than fence rw, w, it gives an additional fence r, r barrier. > > That for (part of) smp_store_release(). Let me stress that my option > (c) was meant to include similar changes for _every releases (that is, > cmpxchg_release(), atomic_inc_return_release(), and many other), even > if most of such releases do not currently create "problematic pairs" > with a corresponding acquire: the concern is that future changes in the > RISC-V atomics implementation or in generic locking code will introduce > pairs of the form FENCE RW,W + .AQ or .RL + FENCE R,RW without anyone > noticing... In other words, I was suggesting that RISC-V _continues > to meet the ordering property under discussion "by design" rather than > "by Andrea or whoever's code auditing/review" (assuming it's feasible, > i.e. that it doesn't clash with other people's arguments?); options (a) > and (b) were also "designed" following this same criterion. > > Andrea -- Best Regards Guo Ren ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [External] Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-18 16:48 ` Guo Ren 2025-09-18 21:24 ` Andrea Parri @ 2025-09-19 3:18 ` Xu Lu 2025-09-19 7:45 ` Andrea Parri 2025-09-20 6:04 ` Guo Ren 1 sibling, 2 replies; 18+ messages in thread From: Xu Lu @ 2025-09-19 3:18 UTC (permalink / raw) To: Guo Ren Cc: Andrea Parri, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe [-- Attachment #1: Type: text/plain, Size: 4396 bytes --] Hi Guo Ren, Thanks for your advice. On Fri, Sep 19, 2025 at 12:48 AM Guo Ren <guoren@kernel.org> wrote: > > On Wed, Sep 17, 2025 at 12:01:34AM -0400, Guo Ren wrote: > > On Tue, Sep 02, 2025 at 06:59:15PM +0200, Andrea Parri wrote: > > > > Xu Lu (4): > > > > riscv: add ISA extension parsing for Zalasr > > > > dt-bindings: riscv: Add Zalasr ISA extension description > > > > riscv: Instroduce Zalasr instructions > > > > riscv: Use Zalasr for smp_load_acquire/smp_store_release > > > > > > Informally put, our (Linux) memory consistency model specifies that any > > > sequence > > > > > > spin_unlock(s); > > > spin_lock(t); > > > > > > behaves "as it provides at least FENCE.TSO ordering between operations > > > which precede the UNLOCK+LOCK sequence and operations which follow the > > > sequence". Unless I missing something, the patch set in question breaks > > > such ordering property (on RISC-V): for example, a "release" annotation, > > > .RL (as in spin_unlock() -> smp_store_release(), after patch #4) paired > > > with an "acquire" fence, FENCE R,RW (as could be found in spin_lock() -> > > > atomic_try_cmpxchg_acquire()) do not provide the specified property. > > > > > > I _think some solutions to the issue above include: > > > > > > a) make sure an .RL annotation is always paired with an .AQ annotation > > > and viceversa an .AQ annotation is paired with an .RL annotation > > > (this approach matches the current arm64 approach/implementation); > > > > > > b) on the opposite direction, always pair FENCE R,RW (or occasionally > > > FENCE R,R) with FENCE RW,W (this matches the current approach/the > > > current implementation within riscv); > > > > > > c) mix the previous two solutions (resp., annotations and fences), but > > > make sure to "upgrade" any releases to provide (insert) a FENCE.TSO. > > I prefer option c) at first, it has fewer modification and influence. > Another reason is that store-release-to-load-acquire would give out a > FENCE rw, rw according to RVWMO PPO 7th rule instead of FENCE.TSO, which > is stricter than the Linux requirement you've mentioned. The existing implementation of spin_unlock, when followed by spin_lock, is equal to 'FENCE rw, rw' for operations before spin_unlock and after spin_lock: spin_unlock: fence rw, w sd spin_lock: amocas fence r, rw The store-release semantics in spin_unlock, is used to ensure that when the other cores can watch the store, they must also watch the operations before the store, which is a more common case than calling spin_unlock immediately followed by spin_lock on the same core. And the existing implementation 'fence rw, w' 'fence r, rw' is stricter than '.aq' '.rl'. That is why we want to modify it. I have reimplemented the code and it now looks like the attached text file. I will send the patch out later. Best Regards. Xu Lu > > > > > asm volatile(ALTERNATIVE("fence rw, w;\t\nsb %0, 0(%1)\t\n", \ > > - SB_RL(%0, %1) "\t\nnop\t\n", \ > > + SB_RL(%0, %1) "\t\n fence.tso;\t\n", \ > > 0, RISCV_ISA_EXT_ZALASR, 1) \ > > : : "r" (v), "r" (p) : "memory"); \ > > > > I didn't object option a), and I think it could be done in the future. > > Acquire Zalasr extension step by step. > > > > > > > > (a) would align RISC-V and ARM64 (which is a good thing IMO), though it > > > is probably the most invasive approach among the three approaches above > > > (requiring certain changes to arch/riscv/include/asm/{cmpxchg,atomic}.h, > > > which are already relatively messy due to the various ZABHA plus ZACAS > > > switches). Overall, I'm not too exited at the idea of reviewing any of > > > those changes, but if the community opts for it, I'll almost definitely > > > take a closer look with due calm. ;-) > > > > > > Andrea > > > > > > _______________________________________________ > > > linux-riscv mailing list > > > linux-riscv@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > _______________________________________________ > > linux-riscv mailing list > > linux-riscv@lists.infradead.org > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > [-- Attachment #2: zalasr.txt --] [-- Type: text/plain, Size: 1761 bytes --] |----------------------------------------------------------------------------------------------| | | arch_xchg_release | arch_cmpxchg_release | __smp_store_release | | |-----------------------------------------------------------------------------------------| | | zabha | !zabha | zabha+zacas | !(zabha+zacas) | zalasr | !zalasr | | rl |-----------------------------------------------------------------------------------------| | | | (fence rw, w) | | (fence rw, w) | | fence rw, w | | | amoswap.rl | lr.w | amocas.rl | lr.w | s{b|h|w|d}.rl | s{b|h|w|d} | | | | sc.w.rl | | sc.w.rl | | | |----------------------------------------------------------------------------------------------| | | arch_xchg_acquire | arch_cmpxchg_acquire | __smp_load_acquire | | |-----------------------------------------------------------------------------------------| | | zabha | !zabha | zabha+zacas | !(zabha+zacas) | zalasr | !zalasr | | aq |-----------------------------------------------------------------------------------------| | | | lr.w.aq | | lr.w.aq | | l{b|h|w|d} | | | amoswap.aq | sc.w | amocas.aq | sc.w | l{b|h|w|d}.aq | fence r, rw | | | | (fence r, rw) | | (fence r, rw) | | | |----------------------------------------------------------------------------------------------| (fence rw, w), (fence r, rw) here means such instructions will only be inserted when zalasr is not implemented. ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [External] Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-19 3:18 ` [External] " Xu Lu @ 2025-09-19 7:45 ` Andrea Parri 2025-09-19 8:22 ` Xu Lu 2025-09-20 6:04 ` Guo Ren 1 sibling, 1 reply; 18+ messages in thread From: Andrea Parri @ 2025-09-19 7:45 UTC (permalink / raw) To: Xu Lu Cc: Guo Ren, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe > The existing implementation of spin_unlock, when followed by > spin_lock, is equal to 'FENCE rw, rw' for operations before This is not true without Zacas, that is, when using LR/SC: write-to-read remains unordered in that case. Andrea ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [External] Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-19 7:45 ` Andrea Parri @ 2025-09-19 8:22 ` Xu Lu 0 siblings, 0 replies; 18+ messages in thread From: Xu Lu @ 2025-09-19 8:22 UTC (permalink / raw) To: Andrea Parri Cc: Guo Ren, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe Hi Andrea, On Fri, Sep 19, 2025 at 3:45 PM Andrea Parri <parri.andrea@gmail.com> wrote: > > > The existing implementation of spin_unlock, when followed by > > spin_lock, is equal to 'FENCE rw, rw' for operations before > > This is not true without Zacas, that is, when using LR/SC: write-to-read > remains unordered in that case. Yes. Thanks for your corrections. The LR/SC here, when Zacas or Zabha is not implemented, will behaves like: fence rw, w sd lr.w sc,w fence r, rw The 'fence rw, w' ensures the order of operations before itself and 'sc.w'. The 'fence r, rw' ensures the order of operations after itself and 'lr.w'. The operations between 'lr.w' and 'sc.w' are as few as possible and cannot contain load or stores as is said in section 13.3 of riscv unpriv spec: "The dynamic code executed between the LR and SC instructions can only contain instructions from the base ''I'' instruction set, excluding loads, stores, backward jumps, taken backward branches, JALR, FENCE, and SYSTEM instructions." So in summary, though it does not provide 'fence rw, rw' semantics, there is limited space available for the CPU to reorder. And, still, I think calling spin_unlock immediately followed by spin_lock on the same core is much rarer than calling spin_unlock on one core and spin_lock on another core. Best regards, Xu Lu > > Andrea ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [External] Re: [PATCH v2 0/4] riscv: Add Zalasr ISA extension support 2025-09-19 3:18 ` [External] " Xu Lu 2025-09-19 7:45 ` Andrea Parri @ 2025-09-20 6:04 ` Guo Ren 1 sibling, 0 replies; 18+ messages in thread From: Guo Ren @ 2025-09-20 6:04 UTC (permalink / raw) To: Xu Lu Cc: Andrea Parri, robh, krzk+dt, conor+dt, paul.walmsley, palmer, aou, alex, ajones, brs, devicetree, linux-riscv, linux-kernel, apw, joe On Fri, Sep 19, 2025 at 11:18 AM Xu Lu <luxu.kernel@bytedance.com> wrote: > > Hi Guo Ren, > > Thanks for your advice. > > On Fri, Sep 19, 2025 at 12:48 AM Guo Ren <guoren@kernel.org> wrote: > > > > On Wed, Sep 17, 2025 at 12:01:34AM -0400, Guo Ren wrote: > > > On Tue, Sep 02, 2025 at 06:59:15PM +0200, Andrea Parri wrote: > > > > > Xu Lu (4): > > > > > riscv: add ISA extension parsing for Zalasr > > > > > dt-bindings: riscv: Add Zalasr ISA extension description > > > > > riscv: Instroduce Zalasr instructions > > > > > riscv: Use Zalasr for smp_load_acquire/smp_store_release > > > > > > > > Informally put, our (Linux) memory consistency model specifies that any > > > > sequence > > > > > > > > spin_unlock(s); > > > > spin_lock(t); > > > > > > > > behaves "as it provides at least FENCE.TSO ordering between operations > > > > which precede the UNLOCK+LOCK sequence and operations which follow the > > > > sequence". Unless I missing something, the patch set in question breaks > > > > such ordering property (on RISC-V): for example, a "release" annotation, > > > > .RL (as in spin_unlock() -> smp_store_release(), after patch #4) paired > > > > with an "acquire" fence, FENCE R,RW (as could be found in spin_lock() -> > > > > atomic_try_cmpxchg_acquire()) do not provide the specified property. > > > > > > > > I _think some solutions to the issue above include: > > > > > > > > a) make sure an .RL annotation is always paired with an .AQ annotation > > > > and viceversa an .AQ annotation is paired with an .RL annotation > > > > (this approach matches the current arm64 approach/implementation); > > > > > > > > b) on the opposite direction, always pair FENCE R,RW (or occasionally > > > > FENCE R,R) with FENCE RW,W (this matches the current approach/the > > > > current implementation within riscv); > > > > > > > > c) mix the previous two solutions (resp., annotations and fences), but > > > > make sure to "upgrade" any releases to provide (insert) a FENCE.TSO. > > > I prefer option c) at first, it has fewer modification and influence. > > Another reason is that store-release-to-load-acquire would give out a > > FENCE rw, rw according to RVWMO PPO 7th rule instead of FENCE.TSO, which > > is stricter than the Linux requirement you've mentioned. > > The existing implementation of spin_unlock, when followed by > spin_lock, is equal to 'FENCE rw, rw' for operations before Yes, it's also stricter than option c), the same as ".RL->.AQ" sequence. You give out another reason for option c). > spin_unlock > and after spin_lock: > > spin_unlock: > fence rw, w > sd > spin_lock: > amocas > fence r, rw > > The store-release semantics in spin_unlock, is used to ensure that > when the other cores can watch the store, they must also watch the > operations before the store, which is a more common case than calling > spin_unlock immediately followed by spin_lock on the same core. And > the existing implementation 'fence rw, w' 'fence r, rw' is stricter > than '.aq' '.rl'. That is why we want to modify it. > > I have reimplemented the code and it now looks like the attached text > file. I will send the patch out later. > > Best Regards. > > Xu Lu > > > > > > > > > asm volatile(ALTERNATIVE("fence rw, w;\t\nsb %0, 0(%1)\t\n", \ > > > - SB_RL(%0, %1) "\t\nnop\t\n", \ > > > + SB_RL(%0, %1) "\t\n fence.tso;\t\n", \ > > > 0, RISCV_ISA_EXT_ZALASR, 1) \ > > > : : "r" (v), "r" (p) : "memory"); \ > > > > > > I didn't object option a), and I think it could be done in the future. > > > Acquire Zalasr extension step by step. > > > > > > > > > > > (a) would align RISC-V and ARM64 (which is a good thing IMO), though it > > > > is probably the most invasive approach among the three approaches above > > > > (requiring certain changes to arch/riscv/include/asm/{cmpxchg,atomic}.h, > > > > which are already relatively messy due to the various ZABHA plus ZACAS > > > > switches). Overall, I'm not too exited at the idea of reviewing any of > > > > those changes, but if the community opts for it, I'll almost definitely > > > > take a closer look with due calm. ;-) > > > > > > > > Andrea > > > > > > > > _______________________________________________ > > > > linux-riscv mailing list > > > > linux-riscv@lists.infradead.org > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > > > > > > > > _______________________________________________ > > > linux-riscv mailing list > > > linux-riscv@lists.infradead.org > > > http://lists.infradead.org/mailman/listinfo/linux-riscv > > > -- Best Regards Guo Ren ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2025-09-20 6:04 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-09-02 4:24 [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Xu Lu 2025-09-02 4:24 ` [PATCH v2 1/4] riscv: add ISA extension parsing for Zalasr Xu Lu 2025-09-02 4:24 ` [PATCH v2 2/4] dt-bindings: riscv: Add Zalasr ISA extension description Xu Lu 2025-09-02 19:46 ` Conor Dooley 2025-09-02 4:24 ` [PATCH v2 3/4] riscv: Instroduce Zalasr instructions Xu Lu 2025-09-02 4:24 ` [PATCH v2 4/4] riscv: Use Zalasr for smp_load_acquire/smp_store_release Xu Lu 2025-09-03 1:06 ` kernel test robot 2025-09-02 16:59 ` [PATCH v2 0/4] riscv: Add Zalasr ISA extension support Andrea Parri 2025-09-03 11:41 ` [External] " Xu Lu 2025-09-17 4:01 ` Guo Ren 2025-09-17 4:57 ` Guo Ren 2025-09-18 16:48 ` Guo Ren 2025-09-18 21:24 ` Andrea Parri 2025-09-20 5:59 ` Guo Ren 2025-09-19 3:18 ` [External] " Xu Lu 2025-09-19 7:45 ` Andrea Parri 2025-09-19 8:22 ` Xu Lu 2025-09-20 6:04 ` Guo Ren
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).