From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 0DF1934F486 for ; Tue, 17 Mar 2026 11:32:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773747135; cv=none; b=kaTJGlRtXr33KtGgIMQ3Dg75LY7HwGzoAqQhwdBg6PMb6j598OuIkGj4rKUg/LSeXz8ydZBEvtC9zlsD8J079gjDQ53XJV+2avSf4jhcWTxyNte3nCoc03ySloSVkleYfSRJugchcK4DAB9vLVE/2Hvi4IyGrvmiSQI3ZlqTE1g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773747135; c=relaxed/simple; bh=+YmOaBx+HsryXQJW+c4VhaEdouxRJXYUy4pS8RABD+I=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=om8svT9toa+tAQhlBAL6d2g/7n8bHKevUWzp4r2qoKan90Tnw4FCs7cTLP0W3b3qRWr0xa1lnv+Ng8cMjqnBcI4GXsp3DVQh1rPQB4Dv8rdOg9/GCfsGippeQzOJjl5PPQI7pjLViFkkF4tf2tQ1noE2c4ziVMheVVKrLHw34IU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=me+GRMKr; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="me+GRMKr" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 23CE3C19425; Tue, 17 Mar 2026 11:32:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773747134; bh=+YmOaBx+HsryXQJW+c4VhaEdouxRJXYUy4pS8RABD+I=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=me+GRMKrKfKDD1n4x3ewa4FfZ7LtkHCBZyrLBd1208an4O6YhI1MU4Dl8ZRqrvD7c 5N3MTW7QTnEeZCX3aUeaqRmFDhacsiTnJdYeNZivX5pFrv7MgZ3Z5XHZjV98bdkP9Y akVKSqB7hstAay+11B2z0gijYQTarKOIhSmlFzINCxhgbC0D0RzRt1h54c5094twtl +4Wy2quNje8IrnM6Y9oXcBL0qf3nDDpBc1y4skFiuDwMqPpB0iK/sQhxR2RDsYnjrL h8/jo+WHP8aONb/H2jj019FoiY655uC/uippooOpBU/6jegjkgOC5ZQnb0Bb+hInYS V0r1QUqn3YOoQ== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 3385CF4006C; Tue, 17 Mar 2026 07:32:13 -0400 (EDT) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-01.internal (MEProxy); Tue, 17 Mar 2026 07:32:13 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgdeftdduudegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehrugcu uehivghshhgvuhhvvghlfdcuoegrrhgusgeskhgvrhhnvghlrdhorhhgqeenucggtffrrg htthgvrhhnpedvueehiedtvedtleekuddutefgffdtleetfeetveejveejieehfefhjeei jeefudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe grrhguodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduieejtdehtddtjeel qdeffedvudeigeduhedqrghruggspeepkhgvrhhnvghlrdhorhhgseifohhrkhhofhgrrh gurdgtohhmpdhnsggprhgtphhtthhopeduhedpmhhouggvpehsmhhtphhouhhtpdhrtghp thhtohepkhgvrhhnvghlqdhtvggrmhesrghnughrohhiugdrtghomhdprhgtphhtthhope gtrghtrghlihhnrdhmrghrihhnrghssegrrhhmrdgtohhmpdhrtghpthhtohepmhgrrhhk rdhruhhtlhgrnhgusegrrhhmrdgtohhmpdhrtghpthhtoheprhhoshhtvgguthesghhooh gumhhishdrohhrghdprhgtphhtthhopegtmhhllhgrmhgrshesghhoohhglhgvrdgtohhm pdhrtghpthhtohepqhhpvghrrhgvthesghhoohhglhgvrdgtohhmpdhrtghpthhtohepsh grmhhithholhhvrghnvghnsehgohhoghhlvgdrtghomhdprhgtphhtthhopehsvggrnhhj tgesghhoohhglhgvrdgtohhmpdhrtghpthhtohepfihilhhlmhgtvhhitghkvghrsehgoh hoghhlvgdrtghomh X-ME-Proxy: Feedback-ID: ice86485a:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 03800700065; Tue, 17 Mar 2026 07:32:13 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-ThreadId: A4nMOTjRT8v3 Date: Tue, 17 Mar 2026 12:31:51 +0100 From: "Ard Biesheuvel" To: "Peter Zijlstra" Cc: "Carlos Llamas" , linux-arm-kernel@lists.infradead.org, "Sami Tolvanen" , "Catalin Marinas" , "Will Deacon" , "Josh Poimboeuf" , "Mark Rutland" , "Kees Cook" , "Quentin Perret" , "Steven Rostedt" , "Will McVicker" , "Sean Christopherson" , kernel-team@android.com, linux-kernel@vger.kernel.org Message-Id: In-Reply-To: <20260317112453.GF2872@noisy.programming.kicks-ass.net> References: <20260313061852.4025964-1-cmllamas@google.com> <6053b599-c00e-47d0-8f9c-4554fec6d288@app.fastmail.com> <20260317112453.GF2872@noisy.programming.kicks-ass.net> Subject: Re: [PATCH v7] arm64: implement support for static call trampolines Content-Type: text/plain Content-Transfer-Encoding: 7bit On Tue, 17 Mar 2026, at 12:24, Peter Zijlstra wrote: > On Tue, Mar 17, 2026 at 11:59:49AM +0100, Ard Biesheuvel wrote: > >> > +#define __ARCH_DEFINE_STATIC_CALL_TRAMP(name, target) \ >> > + asm(" .pushsection .static_call.text, \"ax\" \n" \ >> > + " .align 3 \n" \ >> > + " .globl " STATIC_CALL_TRAMP_STR(name) " \n" \ >> > + STATIC_CALL_TRAMP_STR(name) ": \n" \ >> > + " hint 34 /* BTI C */ \n" \ >> > + " adrp x16, 1f \n" \ >> > + " ldr x16, [x16, :lo12:1f] \n" \ >> > + " cbz x16, 0f \n" \ >> > + " br x16 \n" \ >> > + "0: ret \n" \ >> > + " .type " STATIC_CALL_TRAMP_STR(name) ", %function \n" \ >> > + " .size " STATIC_CALL_TRAMP_STR(name) ", . - " >> > STATIC_CALL_TRAMP_STR(name) " \n" \ >> > + " .popsection \n" \ >> > + " .pushsection .rodata, \"a\" \n" \ >> > + " .align 3 \n" \ >> > + "1: .quad " target " \n" \ >> > + " .popsection \n") > >> > +void arch_static_call_transform(void *site, void *tramp, void *func, >> > bool tail) >> > +{ >> > + u64 literal; >> > + int ret; >> > + >> >> Here, set func to &__static_call_return0 if it is NULL. > > I'm confused. NULL is for the static_call_cond() case, where we NO-OP. > And the trampoline above does that cbz 0f to ret. So far so good. > > But ret0 should return 0, and IIRC arm64 uses x0 for the return value. > But I don't see the above clearing it. Hmm? > The RET0 case will tail call __static_call_return0() which will take care of this. I am just saying that the NULL case could just do the same, rather than have a conditional branch in the trampoline, as even in that case, the surrounding code must assume that X0 is clobbered. Alternatively, we could tail call __static_call_nop(), which would do just the 'ret'. IOW, if we guarantee that the target is always set to something appropriate, we can elide the NULL check, and __static_call_return0() and __static_call_nop() are equally appropriate for the NULL case.