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 4DCCA330D54 for ; Fri, 13 Feb 2026 11:56:31 +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=1770983791; cv=none; b=lKQVvArI3f6/g5dUR3ig7M8hg/KGyS3izkGQZjUCURp//qtjrBB+bgmbVWecxS6vuVxpdzAL7FoB45kIholOix+GAsgCQh3XBbaCj87v+k37GVEG+og+Hr/SJ0tFQxold8YIf/FesTeuWqdylwa2MYNT7Vk7sg3YnQIh7/oangs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770983791; c=relaxed/simple; bh=XQNPzZWydc6p77Rgg7V3csOKfyOPpgvpVR5E6zDGYhQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=ROnULSE7gYfXTs5Jlwi6MJN9ak3Y1j+Z5NRYsLRk/vX2kKCQ38PQ1M0GiBonK7htRmfvXrwbPINMwY3dqlZWM7QFQ8Ke3RJaNKjFFfMenj6etQ6lfivM3Xh/v/grZO9WH8J1qq781Ck1YWmsmMq+zY+UQyX1gNIVZ8iy/zZxTMc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=MKpMeL91; 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="MKpMeL91" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4061CC116C6; Fri, 13 Feb 2026 11:56:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770983790; bh=XQNPzZWydc6p77Rgg7V3csOKfyOPpgvpVR5E6zDGYhQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=MKpMeL91vkzu4lrNrwMW7UCg1wpxzL496yPwACeCgxvR74/pQqKlghNhbtOJyFFwE Zqgk6IQHtNf7Z7aGPt2cTuWZh4LydmHns4n1eLaX09J+LTxv1RcTzyJXOI12MknKoq k8/UebDeW5KrMfg8D91SjW2g6gZQPRWlEaA6uFTuNsR6Hmr+Au0mWdOGuBwGbQr1zh 5T4xK9UsjscSgju7qrIn9EAvTUOw+LTNyEGJ/kdPh/jI/TKb3HVXyWEJ9s+xrgdi5N tiLQuHUWzw6AVH9Rm/u4aS9DIEnBOBfyrXDKitfM+D7x/bMAS0B8qVSX8KCcWPypEt C3ms6oY9DGrXw== Date: Fri, 13 Feb 2026 11:56:25 +0000 From: Will Deacon To: Guenter Roeck Cc: Jianpeng Chang , catalin.marinas@arm.com, ying.huang@linux.alibaba.com, ardb@kernel.org, anshuman.khandual@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [v3 PATCH] arm64: mm: Fix kexec failure after pte_mkwrite_novma() change Message-ID: References: <20251204062722.3367201-1-jianpeng.chang.cn@windriver.com> <73e9c019-abd8-4914-a70a-277142e4f306@roeck-us.net> 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: <73e9c019-abd8-4914-a70a-277142e4f306@roeck-us.net> On Thu, Feb 12, 2026 at 10:51:45AM -0800, Guenter Roeck wrote: > On Thu, Dec 04, 2025 at 02:27:22PM +0800, Jianpeng Chang wrote: > > Commit 143937ca51cc ("arm64, mm: avoid always making PTE dirty in > > pte_mkwrite()") modified pte_mkwrite_novma() to only clear PTE_RDONLY > > when the page is already dirty (PTE_DIRTY is set). While this optimization > > prevents unnecessary dirty page marking in normal memory management paths, > > it breaks kexec on some platforms like NXP LS1043. > > > > The issue occurs in the kexec code path: > > 1. machine_kexec_post_load() calls trans_pgd_create_copy() to create a > > writable copy of the linear mapping > > 2. _copy_pte() calls pte_mkwrite_novma() to ensure all pages in the copy > > are writable for the new kernel image copying > > 3. With the new logic, clean pages (without PTE_DIRTY) remain read-only > > 4. When kexec tries to copy the new kernel image through the linear > > mapping, it fails on read-only pages, causing the system to hang > > after "Bye!" > > > > The same issue affects hibernation which uses the same trans_pgd code path. > > > > Fix this by marking pages dirty with pte_mkdirty() in _copy_pte(), which > > ensures pte_mkwrite_novma() clears PTE_RDONLY for both kexec and > > hibernation, making all pages in the temporary mapping writable regardless > > of their dirty state. This preserves the original commit's optimization > > for normal memory management while fixing the kexec/hibernation regression. > > > > Using pte_mkdirty() causes redundant bit operations when the page is > > already writable (redundant PTE_RDONLY clearing), but this is acceptable > > since it's not a hot path and only affects kexec/hibernation scenarios. > > > > Fixes: 143937ca51cc ("arm64, mm: avoid always making PTE dirty in pte_mkwrite()") > > Signed-off-by: Jianpeng Chang > > Reviewed-by: Huang Ying > > We (Google) experience this problem with servers utilizing the Ampere Siryn > CPU. It now bubbled down all the way to v6.6.y (and maybe further), > essentially making kexec unusable on affected systems unless the backport > of commit 143937ca51cc is dropped. > > What is the status of this patch ? Catalin and I would prefer to treat kernel mappings as dirty, as suggested in: https://lore.kernel.org/r/aVgUPNzXHHIBhh5A@arm.com If somebody sends a (tested) patch, we'll take it. Will