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 46A4B33122C for ; Mon, 16 Feb 2026 15:33:18 +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=1771255998; cv=none; b=iDjz2FPXEGAXRLrXgxPK/occiaaF7BJi41Omtp5TjTD+dlcDjtSYsJLxRCNKD3awYbG7yunMe/5Bxw2NWyuUQBUuwE7fiT8wRloBYNwpVWoJgK7gokcumC7/wCpf8lWtGqZeAgHeFjxJoZwxNrhUpLdV+kwrkPKQI4AMPi317rE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771255998; c=relaxed/simple; bh=B/smNXNw4Eq3KyVVAhvZJb6xNJh9+uHMcx2/WDqg4cU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bRjnNcIIt04vI66sRqiFpalHJ/1u6egwSCsSzKLpdjWCn+tgiL2uDPBpkuB/VAZMvJTUmQKXZJeNJnHano4RMM07VPZqw2kOodKHa4DVephJEtgUu4wQ03GNgu84mXQv1JtlAJ4kyOqZQzK3f+Bv44UKCKGRCqReFF68wnAfNdc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=q9HbBfA/; 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="q9HbBfA/" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86396C116C6; Mon, 16 Feb 2026 15:33:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1771255998; bh=B/smNXNw4Eq3KyVVAhvZJb6xNJh9+uHMcx2/WDqg4cU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=q9HbBfA/6p2T/K8zKy7dEI8VyrOyimtIUj4gT1fPAlWPngJZSydr5pIWPGOr5G5Ba /HVYqvwvJ3RvPUDTKOycbYMULoumO2kupygvmQYa1/J+bLQ19OeZ2Dx6MEXe3bP4rm FaFJr2Yh7tF/7ZKVC2QMXZV6SQL1n0tu5DdMiWNDjtaTrdCanNcxbLNxQWhPSfBReu ZF2/vm31iRCy4AULXDK4iEPsKu5R0RR5kw1rMQPVcFFyK/kcuioBGklWed0c/uQ67a iJ14rt79vo69lXZD19f20y67oqdH9y8pkxq1vuopm8skdDm6q95R/MsjuxV0Y8U+g4 +pJelKTKFzR2g== Received: from phl-compute-12.internal (phl-compute-12.internal [10.202.2.52]) by mailfauth.phl.internal (Postfix) with ESMTP id 976E5F4006A; Mon, 16 Feb 2026 10:33:16 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-12.internal (MEProxy); Mon, 16 Feb 2026 10:33:16 -0500 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvudejvdegucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepmfhirhihlhcu ufhhuhhtshgvmhgruhcuoehkrghssehkvghrnhgvlhdrohhrgheqnecuggftrfgrthhtvg hrnhepueeijeeiffekheeffffftdekleefleehhfefhfduheejhedvffeluedvudefgfek necuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepkhhirh hilhhlodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhithihqdduieduudeivdeiheeh qddvkeeggeegjedvkedqkhgrsheppehkvghrnhgvlhdrohhrghesshhhuhhtvghmohhvrd hnrghmvgdpnhgspghrtghpthhtohepvddvpdhmohguvgepshhmthhpohhuthdprhgtphht thhopehthhhomhgrshdrlhgvnhgurggtkhihsegrmhgurdgtohhmpdhrtghpthhtoheprg hruggssehkvghrnhgvlhdrohhrghdprhgtphhtthhopehtghhlgieskhgvrhhnvghlrdho rhhgpdhrtghpthhtohepmhhinhhgohesrhgvughhrghtrdgtohhmpdhrtghpthhtohepsg hpsegrlhhivghnkedruggvpdhrtghpthhtohepuggrvhgvrdhhrghnshgvnheslhhinhhu gidrihhnthgvlhdrtghomhdprhgtphhtthhopeigkeeisehkvghrnhgvlhdrohhrghdprh gtphhtthhopehlihhnuhigqdgvfhhisehvghgvrhdrkhgvrhhnvghlrdhorhhgpdhrtghp thhtoheplhhinhhugidqmhhmsehkvhgrtghkrdhorhhg X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 16 Feb 2026 10:33:16 -0500 (EST) Date: Mon, 16 Feb 2026 15:33:15 +0000 From: Kiryl Shutsemau To: Tom Lendacky Cc: Ard Biesheuvel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, linux-efi@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Moritz Sanft Subject: Re: [PATCH 2/2] efi: Align unaccepted memory range to page boundary Message-ID: References: <20260213154838.46567-1-kas@kernel.org> <20260213154838.46567-3-kas@kernel.org> <86c040be-e91a-4d1d-a365-a3bf3772374f@amd.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: <86c040be-e91a-4d1d-a365-a3bf3772374f@amd.com> On Mon, Feb 16, 2026 at 08:51:17AM -0600, Tom Lendacky wrote: > On 2/13/26 09:48, Kiryl Shutsemau (Meta) wrote: > > The accept_memory() and range_contains_unaccepted_memory() functions > > employ a "guard page" logic to prevent crashes with load_unaligned_zeropad(). > > This logic extends the range to be accepted (or checked) by one unit_size > > if the end of the range is aligned to a unit_size boundary. > > > > However, if the caller passes a range that is not page-aligned, the > > 'end' of the range might not be numerically aligned to unit_size, even > > if it covers the last page of a unit. This causes the "if (!(end % unit_size))" > > check to fail, skipping the necessary extension and leaving the next > > unit unaccepted, which can lead to a kernel panic when accessed by > > load_unaligned_zeropad(). > > > > Align the start address down and the size up to the nearest page > > boundary before performing the unit_size alignment check. This ensures > > that the guard unit is correctly added when the range effectively ends > > on a unit boundary. > > > > Signed-off-by: Kiryl Shutsemau (Meta) > > --- > > drivers/firmware/efi/unaccepted_memory.c | 12 ++++++++++-- > > 1 file changed, 10 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/firmware/efi/unaccepted_memory.c b/drivers/firmware/efi/unaccepted_memory.c > > index c2c067eff634..9ddf3dedd514 100644 > > --- a/drivers/firmware/efi/unaccepted_memory.c > > +++ b/drivers/firmware/efi/unaccepted_memory.c > > @@ -35,14 +35,18 @@ void accept_memory(phys_addr_t start, unsigned long size) > > struct efi_unaccepted_memory *unaccepted; > > unsigned long range_start, range_end; > > struct accept_range range, *entry; > > - phys_addr_t end = start + size; > > unsigned long flags; > > + phys_addr_t end; > > u64 unit_size; > > > > unaccepted = efi_get_unaccepted_table(); > > if (!unaccepted) > > return; > > > > + start = PAGE_ALIGN_DOWN(start); > > + size = PAGE_ALIGN(size); > > + end = start + size; > > Should this really be: > > end = PAGE_ALIGN(start + size); > start = PAGE_ALIGN_DOWN(start); > > ? Doh! Yes, you are right. -- Kiryl Shutsemau / Kirill A. Shutemov