From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18])
	(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 B871319644B
	for <linux-kernel@vger.kernel.org>; Tue, 18 Aug 2026 00:30:17 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t=1787013018; cv=none; b=VOfN/PT15VcIFklT8h1ZnNUEjTA9Y8rMBJnqliwutJi7TBDxU00kUad6uEmEjajzqwjv5AnjRWqa55cN1Ae+C3zFPWMoDjJ5C+TJdPLIQLvznljQOuSealiI6Gqn5GiBocGnmlEQsW9Tw3tMHqLQ2hcSHTyGG+ZoA70NOwahP1A=
ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t=1787013018; c=relaxed/simple;
	bh=zZL3P761DWLL2qWX3GI5/qjZyIt4UmkQRKvwwPWUwUo=;
	h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:
	 Content-Type:Content-Disposition:In-Reply-To; b=YAHyXPE7Qg5nYyEQq3sviYhyEvPSZO6S2oo0SfoXDpurG3x8lyAbOovTiEdEo4eyRB6ODhQFBkafukr/1Fyia6fBtuGJRxbx4/GekDpHgs6jL6xZenFca0Qhby9/4/UUee7aH7OOYJcgTSVpAMzFNg/m/Z0jUcn3pQR6rldBsTs=
ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=G9DmyQJl; arc=none smtp.client-ip=100.103.45.18
Authentication-Results: smtp.subspace.kernel.org;
	dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="G9DmyQJl"
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5980B1F00A3D;
	Tue, 18 Aug 2026 00:30:16 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org;
	s=k20260515; t=1787013017;
	bh=tqpm/MsF9EtapjtjSkpZVHhqSfnCpqB9+EaiEMe+rWk=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To;
	b=G9DmyQJlYXMGxO+kJ58x5iAqxVtHA1mCBKq7KNZdvUlWR9XJ5HaEtnQyLfTa7O6wd
	 LzYopOaIa5luNcZ6t0F2z5rKjyAzIj30XndYk7TjG3ZCXcUij+GYhlWIuSn9rptISU
	 mftiKy/GY8GKpiUP6hHnEm6bkVa5iNFUZhZNeHVPKD8ewpOTuA039+1E+VTUK43Y5h
	 vELvAES6yBe85FPFcqP70xoeis8ECjERLaHMkidindQ1MZROLNj2Mj/gI8Ylq2u+cS
	 W1shudVIGjfNLLrOAywROLUzVmX2SL8VkMTXLT9B1eLeDArlK6NoF00A4zg5hW7yFv
	 JOw4DrvLpLjXw==
Date: Tue, 18 Aug 2026 00:30:15 +0000
From: Yosry Ahmed <yosry@kernel.org>
To: Brendan Jackman <brendan.jackman@linux.dev>
Cc: Brendan Jackman <jackmanb@google.com>, Borislav Petkov <bp@alien8.de>, 
	Dave Hansen <dave.hansen@linux.intel.com>, Peter Zijlstra <peterz@infradead.org>, 
	Andrew Morton <akpm@linux-foundation.org>, David Hildenbrand <david@kernel.org>, 
	Vlastimil Babka <vbabka@kernel.org>, Mike Rapoport <rppt@kernel.org>, Wei Xu <weixugc@google.com>, 
	Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>, Lorenzo Stoakes <ljs@kernel.org>, 
	linux-mm@kvack.org, linux-kernel@vger.kernel.org, x86@kernel.org, 
	Sumit Garg <sumit.garg@oss.qualcomm.com>, Will Deacon <will@kernel.org>, rientjes@google.com, 
	"Kalyazin, Nikita" <kalyazin@amazon.co.uk>, patrick.roy@linux.dev, "Itazuri, Takahiro" <itazur@amazon.co.uk>, 
	Andy Lutomirski <luto@kernel.org>, David Kaplan <david.kaplan@amd.com>, 
	Thomas Gleixner <tglx@kernel.org>, Patrick Bellasi <derkling@google.com>, 
	Reiji Watanabe <reijiw@google.com>, Sean Christopherson <seanjc@google.com>
Subject: Re: [PATCH v3 04/26] x86/mm: split out preallocate_sub_pgd()
Message-ID: <aoOngGT0tz5T9Zkm@google.com>
References: <20260726-page_alloc-unmapped-v3-0-6f5729aa9832@google.com>
 <20260726-page_alloc-unmapped-v3-4-6f5729aa9832@google.com>
 <am0aplxsh1b16Rch@google.com>
 <DKNXIWKP5KIO.1YT877KQJN0IF@linux.dev>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <DKNXIWKP5KIO.1YT877KQJN0IF@linux.dev>

> >> +
> >> +	/*
> >> +	 * On 4-level systems, the P4D layer is folded away and
> >> +	 * the above code does no preallocation.  Below, go down
> >> +	 * to the pud _software_ level to ensure the second
> >> +	 * hardware level is allocated on 4-level systems too.
> >> +	 */
> >> +	lvl = "pud";
> >> +	pud = pud_alloc(mm, p4d, addr);
> >> +	if (!pud)
> >> +		goto failed;
> >> +	return 0;
> >> +
> >> +failed:
> >> +	pr_warn_ratelimited("Failed to preallocate %s\n", lvl);
> >
> > Can this possibly fire more than once? IIUC we will panic right after
> > returning.
> 
> In the immediate usecase no, but once it's used for
> mm_local_map_to_user() we do actually handle failure.

Oh yeah I missed this, thanks.