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 2BB712B9BA for ; Mon, 24 Nov 2025 19:10:28 +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=1764011429; cv=none; b=t9usNGZiLCgZFOXtQvZEU1x26kmLBdzrf8RbIO0CJpqPNvL5iMoIw115WdfiJjouKYa1OFTFH3NEeOjQPGA3q5lXrA5rD37qK7nJ4/NDg5J5L0TVvS2SD8twGOw2NLbNrGUMfkmObCWpc0yOZyhDnCs8X8vhpq1d1Hz0uMeeshk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764011429; c=relaxed/simple; bh=JPqHRqXoVR3BFq0YCOeqZBWcEnjcQXFhJQoaGkZKN9o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=k0sTUPuhPTzGHhKE1WgwWLw/VcfGn3oQkfeMFqxpcG3XOj2IOXMRA68Fty7Hi+0H6ABs2vS3fkaMY4QY/MigpObP7oCpJaCS5PXsK5QB18rLKCnx8LyQLviyn1Xab7EBXQUfs9des2s6RLpKZ0dGtjgbPiuirkhGt8D7Mf7kgqI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=YjcORZUH; 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="YjcORZUH" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EA665C4CEF1; Mon, 24 Nov 2025 19:10:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764011428; bh=JPqHRqXoVR3BFq0YCOeqZBWcEnjcQXFhJQoaGkZKN9o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YjcORZUHd3J4egMs+Z1WXfvFQO5wqEjUs0zUBCntkEsRsSx59bFpjToqOj6DG6WF4 7fpI/CLYrNjZn33PpLMajFtYeqFubLsTCV3VXAtYWNmBJ2gtx4HeunMHC+QkVD2jRX Lcph2BMki+0UQ3IOBjkn/yIzhJ/xACsHr49h3j3HcoPIGUVSpQi0D6K7gD/0z2cEap /i6s/IQzvBtM0aj9R9dtXKOCM6j95PirY2lJsCS/6Exsib+sf8CEwaYVotgliJYtFh 5i9909+josZ12x1POdHWTPH3yDMpzWVMfWavoTSBH/4wMtW1VZpvYqo3LuOMQUmYQ+ f3OhxyghRCRCg== Date: Mon, 24 Nov 2025 19:10:23 +0000 From: Will Deacon To: Ryan Roberts Cc: Dev Jain , catalin.marinas@arm.com, rppt@kernel.org, shijie@os.amperecomputing.com, yang@os.amperecomputing.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] arm64/pageattr: Propagate return value from __change_memory_common Message-ID: References: <20251112062716.64801-1-dev.jain@arm.com> <20251112062716.64801-2-dev.jain@arm.com> <6bc0fac0-3c00-4ecf-948e-5648584ec939@arm.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: On Mon, Nov 24, 2025 at 06:09:31PM +0000, Ryan Roberts wrote: > On 24/11/2025 15:11, Will Deacon wrote: > > On Thu, Nov 13, 2025 at 11:55:48AM +0000, Ryan Roberts wrote: > >> On 12/11/2025 06:27, Dev Jain wrote: > >>> The rodata=on security measure requires that any code path which does > >>> vmalloc -> set_memory_ro/set_memory_rox must protect the linear map alias > >>> too. Therefore, if such a call fails, we must abort set_memory_* and caller > >>> must take appropriate action; currently we are suppressing the error, and > >>> there is a real chance of such an error arising post commit a166563e7ec3 > >>> ("arm64: mm: support large block mapping when rodata=full"). Therefore, > >>> propagate any error to the caller. > >>> > >>> Fixes: a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full") > >>> Signed-off-by: Dev Jain > >> > >> Reviewed-by: Ryan Roberts > >> > >> It would be good to get this into v6.18 I guess? > > > > I'm not sure I see the urgency. When the commit message says: > > > > "there is a real chance of such an error arising post commit a166563e7ec3" > > > > afaict that's either due to -ENOMEM > > Yes this is the main risk; failing to allocate an intermediate page table during > split_kernel_leaf_mapping(). I have no idea how likely that is in production. > The only data point I have is that for the theoretical memory hotplug -ENOMEM > that Chaitanya and Linu fixed recently, we tried to provoke it by hotplugging a > lot of memory on a system under high memory pressure; no matter what we did, we > couldn't get that 4K pgtable allocation to fail. So on that basis, I think we > are unlikely to see it. > > > or some hideous issue with the > > page-tables (e.g. the -EINVALs in pageattr_pXd_entry() seem completely > > unnecessary to me). > > I thought the -EINVALs were trying to catch the case where someone tries to set > permissions on a sub-portion of a vmalloc_huge() area on a system that doesn't > support BBML2_NOABORT. But looking again, we already refuse vmalloc_huge in > change_memory_common. > > > > > Do you think failure is actually likely and recoverable? > > As above, I think failure is unlikely, but not impossible. I guess the result > would be memory that remains RW when it should have been set RO or RX. But I > think it will all work itself out at vfree. I think. > > We can defer this to next cycle if you prefer. Yeah, I think we have bigger problems if we can't find memory to allocate page tables tbh. Will