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 09F292877FE for ; Mon, 2 Feb 2026 07:43:56 +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=1770018236; cv=none; b=hMDtIgfm5L65/b1UJTucpqM5fDlcRdGAs9DsCCvHOufVwIuawExxxejtINCqRfs3YACMcne7doUUJm+29AdV7W5voxdUIDHSG60YtwYMFwCRr/3UwtRh9hegmjVgc5rJqw7PY7P7z6D3Qhg1BQx8OLVCfkNy0g94atWfX54KvVc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770018236; c=relaxed/simple; bh=Wx6zDnajmZZdgiHVlWIKBs8yudA1QP5iyWHbsFAQdLQ=; h=MIME-Version:Date:From:To:Cc:Message-Id:In-Reply-To:References: Subject:Content-Type; b=rImn5iKqGcVYkyid9PuR2zd+Qnum6JqC3G+O8FiXGn8aqaF2YGhsv0QkT7NUhJNCtSvw5vaT2GYcxfEeW4KMRqUI1yKtXGDrhRhHxaTytJ8c71tfSNdFarqo2SsjwSDi8pyzUBpkZeV3DevllodSrs3ATMBG7LO0ZlHsBtJB8/4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=HVcBQxLT; 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="HVcBQxLT" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4E9AFC4AF0B; Mon, 2 Feb 2026 07:43:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770018235; bh=Wx6zDnajmZZdgiHVlWIKBs8yudA1QP5iyWHbsFAQdLQ=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=HVcBQxLTn4UjZnq7J+5Fs086qlBUOTmwv7OeLyww2/ZP9HTfRqVIzU4MbogF/6VJK FgrMjRkWSai0c7nyHtgK168o+hUiMKPXL0E+z165pmp0qg1fuvFZQ38ewrq1IJJNmm 6lG6p131ma9B+4EfA/Y5DERj+RODI2MNXbxm6Ya8hIpQKxKYB1qWzpSbvzzFHDAJbm uNmcN5RJCYGUw4W7oFb5uKjfs1K3BxV6GtetPuP98VeubJZb4lt76xz9KHcvflZ1Zr cKUjxYwQa8atrrj9ss3YAFhPrt+mAso0zAYmP3A+fsq9fiZXEbLV8HMn46vvVCZ6Dz pk4HUFy1KZ3Zw== Received: from phl-compute-01.internal (phl-compute-01.internal [10.202.2.41]) by mailfauth.phl.internal (Postfix) with ESMTP id 54B85F4007C; Mon, 2 Feb 2026 02:43:54 -0500 (EST) Received: from phl-imap-02 ([10.202.2.81]) by phl-compute-01.internal (MEProxy); Mon, 02 Feb 2026 02:43:54 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddujeejtdejucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgfgsehtjeertdertddtnecuhfhrohhmpedftehrugcu uehivghshhgvuhhvvghlfdcuoegrrhgusgeskhgvrhhnvghlrdhorhhgqeenucggtffrrg htthgvrhhnpeetkeehudehiedufefhjeeiffeugeeltdfghfdtffeftdeivdehhfefieeu tedttdenucffohhmrghinhepphhrohgtrdhssgenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpegrrhguodhmvghsmhhtphgruhhthhhpvghrshho nhgrlhhithihqdduieejtdehtddtjeelqdeffedvudeigeduhedqrghruggspeepkhgvrh hnvghlrdhorhhgseifohhrkhhofhgrrhgurdgtohhmpdhnsggprhgtphhtthhopedugedp mhhouggvpehsmhhtphhouhhtpdhrtghpthhtoheptggrthgrlhhinhdrmhgrrhhinhgrsh esrghrmhdrtghomhdprhgtphhtthhopeguvghvrdhjrghinhesrghrmhdrtghomhdprhgt phhtthhopehrhigrnhdrrhhosggvrhhtshesrghrmhdrtghomhdprhgtphhtthhopegrrh hnugesrghrnhgusgdruggvpdhrtghpthhtoheptghlsehgvghnthifohdrohhrghdprhgt phhtthhopeifihhllheskhgvrhhnvghlrdhorhhgpdhrtghpthhtoheplhhinhhugidqmh hmsehkvhgrtghkrdhorhhgpdhrtghpthhtoheprghkphhmsehlihhnuhigqdhfohhunhgu rghtihhonhdrohhrghdprhgtphhtthhopehlihhnuhigqdgrrhhmqdhkvghrnhgvlheslh hishhtshdrihhnfhhrrgguvggrugdrohhrgh X-ME-Proxy: Feedback-ID: ice86485a:Fastmail Received: by mailuser.phl.internal (Postfix, from userid 501) id 28379700065; Mon, 2 Feb 2026 02:43:54 -0500 (EST) 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: AF_iGlW-huzg Date: Mon, 02 Feb 2026 08:43:32 +0100 From: "Ard Biesheuvel" To: "Arnd Bergmann" , "Yang Shi" , "Catalin Marinas" , "Will Deacon" , "Ryan Roberts" , "Andrew Morton" , "David Hildenbrand" , "Lorenzo Stoakes" , "Dev Jain" , scott@os.amperecomputing.com, "Christoph Lameter (Ampere)" Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Message-Id: In-Reply-To: References: <20250917190323.3828347-1-yang@os.amperecomputing.com> <20250917190323.3828347-5-yang@os.amperecomputing.com> Subject: Re: [PATCH v8 4/5] arm64: mm: split linear mapping if BBML2 unsupported on secondary CPUs Content-Type: text/plain Content-Transfer-Encoding: 7bit On Mon, 2 Feb 2026, at 08:18, Arnd Bergmann wrote: > On Wed, Sep 17, 2025, at 21:02, Yang Shi wrote: > >> + .pushsection ".idmap.text", "a" >> +SYM_TYPED_FUNC_START(wait_linear_map_split_to_ptes) >> + /* Must be same registers as in idmap_kpti_install_ng_mappings */ >> + swapper_ttb .req x3 >> + flag_ptr .req x4 >> + >> + mrs swapper_ttb, ttbr1_el1 >> + adr_l flag_ptr, idmap_kpti_bbml2_flag >> + __idmap_cpu_set_reserved_ttbr1 x16, x17 > > I'm getting build failures here, using CONFIG_CFI using clang-21: > > ld.lld-21: error: undefined symbol: __kcfi_typeid_wait_linear_map_split_to_ptes >>>> referenced by arch/arm64/mm/proc.o:(.idmap.text+0x298) in archive vmlinux.a > > I can get it to build by using plain SYM_FUNC_START() instead of > SYM_TYPED_FUNC_START(), but I have no idea if that makes any sense: > > --- a/arch/arm64/mm/proc.S > +++ b/arch/arm64/mm/proc.S > @@ -439,7 +439,7 @@ SYM_FUNC_END(idmap_kpti_install_ng_mappings) > #endif > > .pushsection ".idmap.text", "a" > -SYM_TYPED_FUNC_START(wait_linear_map_split_to_ptes) > +SYM_FUNC_START(wait_linear_map_split_to_ptes) > /* Must be same registers as in idmap_kpti_install_ng_mappings */ > swapper_ttb .req x3 > flag_ptr .req x4 > This is not the right fix: the indirect call from linear_map_split_to_ptes() will be instrumented, and so it requires the CFI annotation to precede the function entry point, which is what SYM_TYPED_FUNC_START() is supposed to emit. The typeid symbol is injected by the compiler into every object file that takes the address of the function in question, and so the fact that it is missing seems to suggest that linear_map_split_to_ptes() has been optimized away entirely. Could you double check arch/arm64/mm/mmu.o if that is the case?