From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B7EDEC5B543 for ; Thu, 5 Jun 2025 06:36:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FDCB6B0167; Thu, 5 Jun 2025 02:36:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4D5B06B0168; Thu, 5 Jun 2025 02:36:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 412376B0169; Thu, 5 Jun 2025 02:36:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 200546B0167 for ; Thu, 5 Jun 2025 02:36:55 -0400 (EDT) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id AC22A161A42 for ; Thu, 5 Jun 2025 06:36:54 +0000 (UTC) X-FDA: 83520389148.20.64D2017 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf29.hostedemail.com (Postfix) with ESMTP id 15BB012000A for ; Thu, 5 Jun 2025 06:36:52 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=c1zmh8cK; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of mingo@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mingo@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749105413; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Hk6Quk8b+Wu0pWn5ogZRCBZm+25NqwqYXwi0nv8OQaY=; b=zjvCqiJh1qq/3s8DUB23gvQVZs+dP4oGZXFHwRxQFiPa+unraQTAULCUE/UzDemJxGzQA5 s9qGIjcBoPOW4L7MCZ9g+WQ7q73CLs1Yf5buI4gz4kkdA9gOgQN6tV1MABnpFXgxyUXsX+ DCgDxD0X90JL37UNEvxeSd0F/Ga+kCE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749105413; a=rsa-sha256; cv=none; b=RGIEQAehlZB+faOrRjzsFzoIr/VSfqRmVbkXJqc4Q88wYGISuHfDQt6ahh9bgtINyFypZl ozOOHQDSaptQbdF3srsPu/hfO5QgUvHAQByHCjhoM3+zjApUJLC+FORq1OE4VaJOiNA4pR 5X5JxY52Uo5d7OtQN0s/mnXDyR0V8Tg= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=c1zmh8cK; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf29.hostedemail.com: domain of mingo@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=mingo@kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 61BC3A5015D; Thu, 5 Jun 2025 06:36:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 609C5C4CEE7; Thu, 5 Jun 2025 06:36:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1749105412; bh=lexn+3RvTYohQzS2vm1pNRLFzrcMJVmP0yTe8m0a7eQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=c1zmh8cK3yfu4BaW+JXF+XxG4WJymnndlXcaPg//PPRYuItmYoX3DSLV6tAslJN1V lS59assDhKUuUq6M2hE/0u5f6Q/LmtsniUdNfDFv2GXYrtA+OLMD0I9laIYE4SR9Uj QAvq4FuwmeVWoZdQ3aSvVfmC9Hx3xTFvpIbNTr7HBxC98VlQJBzOb+KQBw4oyjeeJJ niQXV4JfQo3x/s7OaJkigJ3jsPIbM8kDg0E3KYDFhXrHRrdhlNix6wNBvI5/tQm5gy bruvUwxYI2jzIHzzjX4xAWZf1i0+hllcRJUjEZTr8xt9uDIfJQGqUEGfOMi05YMphz wc2H2eMN2ER4w== Date: Thu, 5 Jun 2025 08:36:45 +0200 From: Ingo Molnar To: Em Sharnoff Cc: linux-kernel@vger.kernel.org, x86@kernel.org, linux-mm@kvack.org, Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , "Edgecombe, Rick P" , Oleg Vasilev , Arthur Petukhovsky , Stefan Radig , Misha Sakhnov Subject: Re: [PATCH] x86/mm: Handle alloc failure in phys_*_init() Message-ID: References: <9f4c0972-a123-4cc3-89f2-ed3490371e65@neon.tech> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9f4c0972-a123-4cc3-89f2-ed3490371e65@neon.tech> X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 15BB012000A X-Stat-Signature: fq48sp1sze9nth9os94wpdsqa9zyuy7h X-Rspam-User: X-HE-Tag: 1749105412-219599 X-HE-Meta: U2FsdGVkX19Uns/yX9uCiPZycQdQzFGqCZoblBSKoCTfEonzdPnCJDCUQTQcedgtXc+o4dcx0cfN3oQonmhd3C6VMl83cynbgQts/uGqNECmhDRsz1dW480N4cA2iUpzGZ2SFgFSm3GFzrrh8FaF/8rq15fVbg64TApnvCBVBQwBnsLSuhRY03NEmyVv3JSMOFdS2b0wQ5Un8hrLzbNpsB8VjTowXuvTKWpaoGtSDZrKJ/rsPZTcAxLHOurK/6m/ncxIzQCFCX1PS9+xHJI96X95gDelH1LUaFEyR2tDn5j+lOLj4gjiDN/ugZBCyUavhjh47GeS9y/GOnUqF6WkxNRrvbw2D71FjkRBpFWvOvoJlCSeGrzioj/QwnoxrSL9c/dXyswnBz4JXKoAA3TUkt15zrS0GxNajtAefvfkTl1uWaAdbwfkCPk6AkyuM7i/v+44mdyWc854bqG+AoYn9ONMitNE5CJNvO23VZfozdKtAaUY3io0urruIIfTCNbtnb44w+ERfrVblV4xQpngW8EzN+vPVwXWVqxU64fel71ETVZPwdbAPfo9r88BgOYTc+czRPwpCi92zfExaPiqMgQjFVKD+NYPVvNo1jQN1aNTtN4py3fbE2KByR/Py5TA4cgA050BKgxD7mbbH9/GR6q6FYJiVyZNDaFVs7Uaj451r2GErCefy6kldbtgHitTwtSkum7d+4nKZ0CdmqdRm7gqgitMUB/Lcmmxxn0igbnzCarp7hBZ1K3lTh7R5J9u2NIkFS2PcoQ6x2C/RIS1AaOr+fydrdNQ6Ugdttvp+kncuWG5mxnWruZIcJeoa72JTC0yjCuhrxC3DVRS1rvCsG8zeHLbQfS2ZSeQ8YowgkZwcjXZ9e08yobdxqfNYzS1L2NjTlM0HiREurg5bGBMCbHhU0nOqgz9WdGowIqtpJoI/XzO8nbkvvgCwc+3zfs4YcHlEysM/e+vs4/04QB vEG/7Crl XRJI4z/5jUCNZ0kUVlXrznmN+gLONGui+IaOj1NL4vVE8zniNIHi+zvpylXXz2N+kb+K4/s3eF53c/MjA28QNXilpcmH/o1ealwTc2PcjrNbEUS8gD5dGi0qpsUGH6M2Syk166iVykCpTi8J6jm8MXO5PLarrGwNdoCgsaXm4ygfR91R3p7dxoEYD4kdRWrwqe6mPG3QzUaR0u+pueE8Wz0NjFu5YyobD7aHoKxZCq9qsNbSrsi23Z48AJ9ZKLZrVqkglH+2Ua+cA0TQ= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: * Em Sharnoff wrote: > tl;dr: > > * When setting up page table mappings for physical addresses after boot, > alloc_low_page() uses GFP_ATOMIC, which is allowed to fail. > * This isn't currently handled, and results in a null pointer > dereference when it occurs. > * This allocation failure can happen during memory hotplug. > > To handle failure, change phys_pud_init() and similar functions to > return zero if allocation failed (either directly or transitively), and > convert that to -ENOMEM in arch_add_memory(). > + /* > + * Bail only after updating pgd/p4d to keep progress from p4d across retries. > + */ > + if (!paddr_last) > + return 0; > + > pgd_changed = true; > - init_memory_mapping(start, start + size, params->pgprot); > + if (!init_memory_mapping(start, start + size, params->pgprot)) > + return -ENOMEM; I agree that it makes total sense to fix all this (especially since you are actively triggering it), but have you tried also changing it away from GFP_ATOMIC? There's no real reason why it should be GFP_ATOMIC AFAICS, other than some historic inertia that nobody bothered to fix. Plus, could you please change the return flow from this zero special-case over to something like ERR_PTR(-ENOMEM) and IS_ERR()? *Technically* zero is a valid physical address, although we intentionally never use it in the kernel AFAIK and wouldn't ever put a page table there either. ERR_PTR()/IS_ERR() is much easier on the eyes than the zero special-case. Finally, could you make this a 2-patch fix series: first one to fix the error return path to not crash, and the second one to change it away from GFP_ATOMIC? Thanks, Ingo