From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from terminus.zytor.com (terminus.zytor.com [198.137.202.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0BCBD399352 for ; Thu, 21 May 2026 10:28:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.136 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779359324; cv=none; b=nDuJQfOS5bc4RV3ub4VtN3A7dvb3Z84AVu/H8UNGKS+I5zqp9GHUPIqL+HEd8cToSwPprfmL4lpK2lb5A4CmIt7ueuFF1ZKrtcVrfkduO0IlurVD8Y+T7brdBJEXVjmg4fLkMZF3TnYpqQNii2A3C/4WhRtTNL4OYf9GGp3AVVM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779359324; c=relaxed/simple; bh=SHYN9cN3gTTG8hE4/Kd6Q/SP+lR3VDd2gSSCp+uFFQ8=; h=Date:From:To:CC:Subject:In-Reply-To:References:Message-ID: MIME-Version:Content-Type; b=J9d5URnDXMQOLLuJtOSs2hPqMM613rtyFNi/bCU9wmUCf10yk2JVOOUonRGL7Uwa9WdTTN1zpcxfLC3MArJpLlJs0BE81gzTkU69tKzaQ0lhR92VZG4nQF4AUEye2uL9v7qQUSDDeO0QpXQzYxUrXIEnIL5jAKo1E8VyrmPbDaU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com; spf=pass smtp.mailfrom=zytor.com; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b=eQMl1WpG; arc=none smtp.client-ip=198.137.202.136 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=zytor.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=zytor.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=zytor.com header.i=@zytor.com header.b="eQMl1WpG" Received: from ehlo.thunderbird.net (c-76-133-66-138.hsd1.ca.comcast.net [76.133.66.138]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 64L9tSO94133346 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 21 May 2026 02:55:28 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 64L9tSO94133346 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2026042601; t=1779357329; bh=t/qcLokcMJP4AvnCTvAvPmWxGwBt+iOc1/6Ja4Rh2Sg=; h=Date:From:To:CC:Subject:In-Reply-To:References:From; b=eQMl1WpGYRzjD13sbobyie77Ulm+FszenA93ggQMsLQ6moMyYUuq7qC2FOSVQv+Dq Lyq/KbPL64i3cNBF3C2agEVykC+i1hEJEUwWruEM66Kb/K20GqAtZKm4137nEBp8FE thnTgB04Y0IQnYCcJHx5QHHoDqfFDLQ9pReQtIWr0ztG9ZFEQQaFEEZr12KJicb3TW FKS7sV1obEBBYNLg9TADY2ePHQ4fb7DsTv0ClhODEwu2EH/LAElIeIj2abMi7OoiZs e2//W9klsD63NwHeSBdsDdWb3QDZGMDLRiGsTyR5WgRhwa4uIBUZ3GvuACdn4y/cvc Vc+vv9kTMWI9w== Date: Thu, 21 May 2026 02:55:22 -0700 From: "H. Peter Anvin" To: Peter Zijlstra , Marco Elver CC: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] x86: Implement _THIS_IP_ using inline asm for 32-bit User-Agent: K-9 Mail for Android In-Reply-To: <20260521070801.GE3126523@noisy.programming.kicks-ass.net> References: <20260521000011.3926424-1-elver@google.com> <20260521070801.GE3126523@noisy.programming.kicks-ass.net> Message-ID: <7B8752AA-2A82-4ABD-BF90-B1A5DCF3F363@zytor.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=utf-8 Content-Transfer-Encoding: quoted-printable On May 21, 2026 12:08:01 AM PDT, Peter Zijlstra wr= ote: >On Thu, May 21, 2026 at 02:00:09AM +0200, Marco Elver wrote: >> Both GCC [1] and Clang [2] consider the generic version of _THIS_IP_ to >> be broken: >>=20 >> #define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)= &&__here; }) >>=20 >> In particular, the address of a label is only expected to be used with = a >> computed goto=2E >>=20 >> While the generic version more or less works today, it is known to be >> brittle and may break with current and future optimizations=2E For >> example, Clang -O2 always returns 1 when this function is inlined: >>=20 >> static inline unsigned long get_ip(void) >> { return ({ __label__ __here; __here: (unsigned long)&&__here; = }); } >>=20 > >Oh gawd :/ > >> Link: https://gcc=2Egnu=2Eorg/bugzilla/show_bug=2Ecgi?id=3D120071 [1] >> Link: https://github=2Ecom/llvm/llvm-project/issues/138272 [2] >> Signed-off-by: Marco Elver >> --- >> arch/x86/include/asm/linkage=2Eh | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >>=20 >> diff --git a/arch/x86/include/asm/linkage=2Eh b/arch/x86/include/asm/li= nkage=2Eh >> index a7294656ad90=2E=2Ebce3c6f4b94f 100644 >> --- a/arch/x86/include/asm/linkage=2Eh >> +++ b/arch/x86/include/asm/linkage=2Eh >> @@ -13,11 +13,12 @@ >> * The generic version tends to create spurious ENDBR instructions und= er >> * certain conditions=2E >> */ >> -#define _THIS_IP_ ({ unsigned long __here; asm ("lea 0(%%rip), %0" : "= =3Dr" (__here)); __here; }) >> +#define _THIS_IP_ ({ unsigned long __here; asm volatile("lea 0(%%rip),= %0" : "=3Dr" (__here)); __here; }) >> #endif >> =20 >> #ifdef CONFIG_X86_32 >> #define asmlinkage CPP_ASMLINKAGE __attribute__((regparm(0))) >> +#define _THIS_IP_ ({ unsigned long __ip; asm volatile("call 1f\n1: pop= %0" : "=3Dr" (__ip)); __ip; }) > >This will mess up the RSB and cause bad performance ripple effects for a >bit each use=2E Now, I don't think anybody still cares about performance >on 32bit (I certainly don't), so perhaps this is fine=2E But urgh=2E Most microarchitectures do *not* have a problem with call/pop, as they kno= w that call with a zero offset is not going to return=2E The main exception= was the Pentium 4=2E