From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from cstnet.cn (smtp25.cstnet.cn [159.226.251.25]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2F06B3998B1 for ; Fri, 17 Jul 2026 12:39:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=159.226.251.25 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784291966; cv=none; b=TdNljvDAAnLu8RTTaj+WgLAxga+pknYEpwDubT6o8XMkOyd1305X+/7kt1pZc70lGB/6/PbOV1evT7C8xjwuyfqXU2zv7kxwmkVWFnlPoUIKbob/X8OQP6IOPCvQzUleNyOMQCXHm8r36aOamcMLti2dJwd1FyE3SlpqW40vCGw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784291966; c=relaxed/simple; bh=UWrBf7qIZhqmKo9kE8F7XH11zUj17OBNLb3ugpIPiYU=; h=Message-ID:Date:MIME-Version:Subject:To:References:From: In-Reply-To:Content-Type; b=Z9F/k1YG736u2bYag1zRZTYAL3KGoqEXkudt3H7pgy42/Dsqh+SlbvwjWYkLGN1ogaqSZ/OeV7qVEI4jg3q4nrBWeYwGdH7+ZQ9nM9e6uAsVAmxotM7p+L+FCez8OfUfmHf2NiYTM+/q4eLi4DHcr9mSaDLfcoFAlJ3+CZ/R8C4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn; spf=pass smtp.mailfrom=iscas.ac.cn; arc=none smtp.client-ip=159.226.251.25 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=iscas.ac.cn Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=iscas.ac.cn Received: from [192.168.0.104] (unknown [123.116.46.73]) by APP-05 (Coremail) with SMTP id zQCowAA3aEJdIlpqSVQHAA--.9369S2; Fri, 17 Jul 2026 20:38:53 +0800 (CST) Message-ID: <0e65ddab-f066-4d9a-b032-d1e55e76fe47@iscas.ac.cn> Date: Fri, 17 Jul 2026 20:38:53 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v3 4/5] riscv: compat_vdso: Build with zacas if available To: Nam Cao , Paul Walmsley , Palmer Dabbelt , Albert Ou , Alexandre Ghiti , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, =?UTF-8?Q?Thomas_Wei=C3=9Fschuh?= , =?UTF-8?Q?Andr=C3=A9_Almeida?= , Mathieu Desnoyers , Thomas Gleixner , Peter Zijlstra , Sebastian Andrzej Siewior References: <704e0bbacee5f23d1351a686f3a783e31699fb3b.1784274927.git.namcao@linutronix.de> Content-Language: en-US From: Vivian Wang In-Reply-To: <704e0bbacee5f23d1351a686f3a783e31699fb3b.1784274927.git.namcao@linutronix.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-CM-TRANSID:zQCowAA3aEJdIlpqSVQHAA--.9369S2 X-Coremail-Antispam: 1UD129KBjvJXoW7CF17WF4UKr4fZw4rArW5Wrg_yoW8ur47pF 4DCrsYgFWDXrWkKrn7Jr4Fq345t3ZYga4agFyjqrWUZ3y5tFy2kwn5t39rWF9rZr1kC3yS vF1I9F1Fkr1DAa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvqb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwACI402YVCY1x02628vn2kIc2xKxwCY 1x0262kKe7AKxVWUtVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8Jw C20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAF wI0_Jw0_GFylIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjx v20xvEc7CjxVAFwI0_Gr0_Cr1lIxAIcVCF04k26cxKx2IYs7xG6r1j6r1xMIIF0xvEx4A2 jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UYxBIdaVFxhVjvjDU0x ZFpf9x07betCcUUUUU= X-CM-SenderInfo: pzdqw2pxlnt03j6l2u1dvotugofq/ Hi Nam, On 7/17/26 16:06, Nam Cao wrote: > The compat vdso Makefile does not enable zacas, disallowing source > files from using zacas instructions. This is an obstacle to adding > robust __vdso_futex_robust_list32_try_unlock() in a follow-up commit. > > Build with zacas, if compiler supports it. > > Signed-off-by: Nam Cao > --- > arch/riscv/kernel/compat_vdso/Makefile | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/arch/riscv/kernel/compat_vdso/Makefile b/arch/riscv/kernel/compat_vdso/Makefile > index 63580b33e3ce..ffbf84aeb081 100644 > --- a/arch/riscv/kernel/compat_vdso/Makefile > +++ b/arch/riscv/kernel/compat_vdso/Makefile > @@ -18,6 +18,10 @@ else > COMPAT_MARCH := rv32imafd > endif > > +ifneq ($(call cc-option,-mabi=ilp32 -march=rv32ima_zacas),) > +COMPAT_MARCH := $(COMPAT_MARCH)_zacas > +endif > + I'm wondering if you would be interested in using .option arch, +zacas for this, instead of enabling it for everything.  I recently found out that we add and *only* add Zacas and Zabha to the global -march for kernel code, just for use in assembly code in arch/riscv/include/asm/cmpxchg.h. So this is *probably* not a correctness problem, since compilers probably don't do atomics on their own accord. However, I personally think it would be a good idea to make everything consistently use .option arch. This makes it so there's no question on what to do to get extension instructions in assembly code - you always do. I have a patch WIP that would make cmpxchg.h use .option arch as well that I will send shortly. You would need to write some more boilerplate: .option push .option arch, +zacas amocas.w.rl ... .option pop Compilation of this code needs to be guarded behind something like if (IS_ENABLED(CONFIG_RISCV_ISA_ZABHA)), which AFAICT your code does. But in exchange for this boilerplate, it would be consistent with stuff like Zbb, and there would be no more need to be plumbing -march around in Makefiles. What do you think? Vivian "dramforever" Wang