Received: by 2002:a05:7412:bbc7:b0:fc:a2b0:25d7 with SMTP id kh7csp954105rdb; Fri, 2 Feb 2024 08:54:45 -0800 (PST) X-Google-Smtp-Source: AGHT+IEHDO01HCmXDgDTwdTKXJcUSPQ0e52vSlugDPJeRk+0hDVnIEjMnSxs/vvXzGCjKAQZE9Qt X-Received: by 2002:a17:907:780c:b0:a37:2675:76a3 with SMTP id la12-20020a170907780c00b00a37267576a3mr886172ejc.74.1706892885313; Fri, 02 Feb 2024 08:54:45 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706892885; cv=pass; d=google.com; s=arc-20160816; b=V8kUIMdGVjx7db+F3ju1UzPWH+QiKa/HrfT9Zw6vDDks24AAT8B7fQtGePnP9xNAIP QSBSh+KAZB8I7bqEWp9m8GvlgJ4+7XKElnuk34BDyCxrfNHI9LkQQaLlN6zHHqGTse3C POcPz5vliPz4dC252fL/+lmSETBohKhM/mKJJGgcyvF9kfy8oGZSma8VTqEqMtzisgwD yPDFZ6FveWnhMQOjl+rficK6gIci073R4/Hm+NB0OHc+ZNbZzNyo3IklRGu4pLRMCqIk UHxnQIiloGPYc0Yqu5vr4p0o5D2ENqM9V8hf4EbBtOp39oBAkojETt8Oi3pG3uOc/Jj4 jWvg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:references:message-id:subject:cc :to:from:date; bh=+TPvHg9HOziBM+HoEueZ+Vuty/OoVE5+yxvHbn887G8=; fh=zmSGcN1I45wzBouk3L/O3jGuhH+vTRcwku+b5zGvFQs=; b=nw0GO30Sc6OXLedWqOaDtjpvBsqJK64uLMW9fqHAwKvOpYIv6Z6Vydx7f/9gCA3u0p S8qgQSoqAzB3/FJFp2CtW4/YPQnkSUt/FTHh3VrIsQtHpi8JfCaiKqeDZl7RC26mBxSY navVx6xMjsvDlai8LeX5VOp0WHKHnDRPcP8/Bo8P8V4KTDy914233gg47+T5WCEH/FZY VQYjcxMo2lg2cN+meYnRqQeYZuaNjZgEPxtYzN6y88SpS3iDp6d0wKvxxIc39+iSHWQA arT0gNV9ZybZWw4UB6vfOViK9VL0mxTfQJYQRwHIcyMNe0YllrvbEUi9B3iRoJ1tfR7M sQSA==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-50182-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50182-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com X-Forwarded-Encrypted: i=1; AJvYcCXqcfD/gTIhiJuWAZYb+bM71bkklxVXBxr/uF9thLoTwY4A4kZEDtb9KUIUpAU9Meg3dekGLyL339VaByb7MnpfC49V0dDVOqBLD4neeQ== Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id d23-20020a17090648d700b00a36fa4806d2si909498ejt.839.2024.02.02.08.54.45 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Feb 2024 08:54:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-50182-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=arm.com dmarc=pass fromdomain=arm.com); spf=pass (google.com: domain of linux-kernel+bounces-50182-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-50182-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id 14BC81F2CAB9 for ; Fri, 2 Feb 2024 16:54:45 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CEDCD1487FB; Fri, 2 Feb 2024 16:54:38 +0000 (UTC) Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id D883A5B66F for ; Fri, 2 Feb 2024 16:54:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706892878; cv=none; b=abtfRS7dhn0elm33Tphib0zxpJPTwjHQHHO4nGYTIVRhPWAg1ecGJ0VpeQp+7oy4nRR67r6ShLj6CdrpIZRGpWi6ipnD1txO9UWcRg3G4ycxQidophFCesud+ScGdHmFwHQAiE+EMrF7Y1uDkC/50T67SpTYPoARUOkhSsdcemk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706892878; c=relaxed/simple; bh=spmM1QubFGEZoJZh8hihiLNYHhNUX0gbSoAYY3JQT9I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XF6DgKosJY0O3TmhDjhDsIPMjmeFfOu32TOjnfZMjVNr3f1UH0Ne7g4VWrL5Gp+E2iNbFmrrGYGgcHwLatplBwzezWQABFuI2dTY0YP/jF2xBNdB+b5nDULFnhl+Exnhshm8o3DhOTG9eF1fMDQ/SxzRUZRs6ntsPphURcGDpgM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D6188DA7; Fri, 2 Feb 2024 08:55:16 -0800 (PST) Received: from e133380.arm.com (e133380.arm.com [10.1.197.58]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2CB093F762; Fri, 2 Feb 2024 08:54:33 -0800 (PST) Date: Fri, 2 Feb 2024 16:54:30 +0000 From: Dave Martin To: Ard Biesheuvel Cc: Fangrui Song , Catalin Marinas , Will Deacon , linux-arm-kernel@lists.infradead.org, Jisheng Zhang , Peter Smith , llvm@lists.linux.dev, linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64: jump_label: use constraints "Si" instead of "i" Message-ID: References: <20240201223545.728028-1-maskray@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Fri, Feb 02, 2024 at 05:32:33PM +0100, Ard Biesheuvel wrote: > On Fri, 2 Feb 2024 at 16:56, Dave Martin wrote: > > > > On Thu, Feb 01, 2024 at 02:35:45PM -0800, Fangrui Song wrote: > > > The generic constraint "i" seems to be copied from x86 or arm (and with > > > a redundant generic operand modifier "c"). It works with -fno-PIE but > > > not with -fPIE/-fPIC in GCC's aarch64 port. > > > > > > The machine constraint "S", which denotes a symbol or label reference > > > with a constant offset, supports PIC and has been available in GCC since > > > 2012 and in Clang since 7.0. However, Clang before 19 does not support > > > "S" on a symbol with a constant offset [1] (e.g. > > > `static_key_false(&nf_hooks_needed[pf][hook])` in > > > include/linux/netfilter.h), so we use "i" as a fallback. > > > > > > Suggested-by: Ard Biesheuvel > > > Signed-off-by: Fangrui Song > > > Link: https://github.com/llvm/llvm-project/pull/80255 [1] > > > > > > --- > > > Changes from > > > arm64: jump_label: use constraint "S" instead of "i" (https://lore.kernel.org/all/20240131065322.1126831-1-maskray@google.com/) > > > > > > * Use "Si" as Ard suggested to support Clang<19 > > > * Make branch a separate operand > > > --- > > > arch/arm64/include/asm/jump_label.h | 12 ++++++++---- > > > 1 file changed, 8 insertions(+), 4 deletions(-) > > > > > > diff --git a/arch/arm64/include/asm/jump_label.h b/arch/arm64/include/asm/jump_label.h > > > index 48ddc0f45d22..1f7d529be608 100644 > > > --- a/arch/arm64/include/asm/jump_label.h > > > +++ b/arch/arm64/include/asm/jump_label.h > > > @@ -15,6 +15,10 @@ > > > > > > #define JUMP_LABEL_NOP_SIZE AARCH64_INSN_SIZE > > > > > > +/* > > > + * Prefer the constraint "S" to support PIC with GCC. Clang before 19 does not > > > + * support "S" on a symbol with a constant offset, so we use "i" as a fallback. > > > + */ > > > static __always_inline bool arch_static_branch(struct static_key * const key, > > > const bool branch) > > > { > > > @@ -23,9 +27,9 @@ static __always_inline bool arch_static_branch(struct static_key * const key, > > > " .pushsection __jump_table, \"aw\" \n\t" > > > " .align 3 \n\t" > > > " .long 1b - ., %l[l_yes] - . \n\t" > > > - " .quad %c0 - . \n\t" > > > + " .quad %0 + %1 - . \n\t" > > > " .popsection \n\t" > > > - : : "i"(&((char *)key)[branch]) : : l_yes); > > > + : : "Si"(key), "i"(branch) : : l_yes); > > > > Is the meaning of multi-alternatives well defined if different arguments > > specify different numbers of alternatives? The GCC documentation says: > > > > https://gcc.gnu.org/onlinedocs/gcc/Multi-Alternative.html: > > > > -8<- > > > > [...] All operands for a single instruction must have the same number of > > alternatives. > > > > ->8- > > > > AIUI that does not apply here. That reasons about multiple arguments > having more than one constraint, where not all combinations of those > constraints are supported by the instruction. Ah, scratch that: I'm confusing multi-alternatives with simple constraints: all arguments must have the same number of comma-separated lists of constraint letters, but each list can contain as many or as few letters as are needed to match the operand. So "Si"(), "i"() is fine. > > Also, I still think it may be redundant to move the addition inside the > > asm, so long as Clang is happy with the symbol having an offset. > > > > Older Clang is not happy with the symbol having an offset. > > And given that the key pointer and the 'branch' boolean are two > distinct inputs to this function, I struggle to understand why you > feel it is better to combine them in the argument. 'branch' is used to > decide whether or not to set bit 0, independently of the value of key. > Using array indexing to combine those values together to avoid an > addition in the asm obfuscates the code. This was more about not making changes that don't need to be made, unless it clearly makes the code better. But if some verions of Clang accept "S" but choke if there's an offset, then moving the addition into the asm seems the way to go. (I may have misread the commit message on this point.) [...] Cheers ---Dave