From nobody Tue Dec 16 21:12:47 2025 Received: from mx0a-0064b401.pphosted.com (mx0a-0064b401.pphosted.com [205.220.166.238]) (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 87A751A9FAF for ; Thu, 4 Dec 2025 06:27:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=205.220.166.238 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764829670; cv=none; b=OM7Bxi8UmZj0lwLOCIkqGJqxjxzKaAJAkX4E0BsVJygRdc2qV8OPtf64kueqvQa9/YK1zarcr/0UW6Gqmuzact4dK0CzDiSUfr31ZPFTcl/bobyNBb3gKEs8o5AHGW+pKzeY0wERxUPn1COqEmnFWbGRI2L/CeUGVfpi/FHv0Ls= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764829670; c=relaxed/simple; bh=y/+eWgjCZUCVG8LFcSm0JbvV93hXqzxVjPA7FT5M8ig=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=j4mZMXPhuXmj1o6FHPNXWhmI2ChVghke2LLd/W6amQdPECHsEKV7J/2xFwk177GbBfpyPWJFkDWh93DOKu1KLeFpse3w4wez0YCuzQPzoKeOQfhtGbsdvlXS7snXijVtUQNqvl257obZcnCv4HF3BPFcfL0oxzNQrFFzfNUiBbo= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=windriver.com; spf=pass smtp.mailfrom=windriver.com; dkim=pass (2048-bit key) header.d=windriver.com header.i=@windriver.com header.b=Du2DPWWa; arc=none smtp.client-ip=205.220.166.238 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=windriver.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=windriver.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=windriver.com header.i=@windriver.com header.b="Du2DPWWa" Received: from pps.filterd (m0250809.ppops.net [127.0.0.1]) by mx0a-0064b401.pphosted.com (8.18.1.11/8.18.1.11) with ESMTP id 5B447kqB3785558; Wed, 3 Dec 2025 22:27:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=windriver.com; h=cc:content-transfer-encoding:content-type:date:from :message-id:mime-version:subject:to; s=PPS06212021; bh=MdrhlJJLi p89KDzEFZOj8aij0kUZ8IVk3riPxg8kaq8=; b=Du2DPWWajOED8qalQ+E05C8IF 4nMqbjEdcJcG4emZaZXf63wchttr86VQauVdxAnHq8bUCXGsxFhPkFsePf7qba81 FUMCcKf+6uWejXLatpMq+VVurPUqz2RWVJkvkBMVYI8JE7QpL5ydzCTcK6kNbyQM y6Y2HQ6z+58tm/hkQuAa4s6jP7ojIYITNL/Lot8QmEskGTxNFM2ISxeKDJqEkvJV BqBA536zMMlFY++7/ePNWv7p4M6o8Zg8fADD7spQ2pSs6fbsrA+BOm1j6OGPBuuv 9G1CGRDmj6k9jn2W+ys3SQqhjKXRq5Yuw+9RwlPTiOTbrc1WgwJ0SYKNxXrJA== Received: from ala-exchng01.corp.ad.wrs.com ([128.224.246.36]) by mx0a-0064b401.pphosted.com (PPS) with ESMTPS id 4ar17mwtck-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 03 Dec 2025 22:27:26 -0800 (PST) Received: from ALA-EXCHNG02.corp.ad.wrs.com (10.11.224.122) by ala-exchng01.corp.ad.wrs.com (10.11.224.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.61; Wed, 3 Dec 2025 22:27:25 -0800 Received: from pek-lpggp9.wrs.com (10.11.232.110) by ALA-EXCHNG02.corp.ad.wrs.com (10.11.224.122) with Microsoft SMTP Server id 15.1.2507.61 via Frontend Transport; Wed, 3 Dec 2025 22:27:23 -0800 From: Jianpeng Chang To: , , , , CC: , , Jianpeng Chang Subject: [v3 PATCH] arm64: mm: Fix kexec failure after pte_mkwrite_novma() change Date: Thu, 4 Dec 2025 14:27:22 +0800 Message-ID: <20251204062722.3367201-1-jianpeng.chang.cn@windriver.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Proofpoint-ORIG-GUID: thNNvrTBKb91gMHjL32t6XFQPA9gLTK3 X-Authority-Analysis: v=2.4 cv=Ws4m8Nfv c=1 sm=1 tr=0 ts=693129ce cx=c_pps a=AbJuCvi4Y3V6hpbCNWx0WA==:117 a=AbJuCvi4Y3V6hpbCNWx0WA==:17 a=wP3pNCr1ah4A:10 a=VkNPw1HP01LnGYTKEx00:22 a=VwQbUJbxAAAA:8 a=t7CeM3EgAAAA:8 a=SRrdq9N9AAAA:8 a=PjQCVsg8d7JXQQm6heoA:9 a=FdTzh2GWekK77mhwV6Dw:22 X-Proofpoint-GUID: thNNvrTBKb91gMHjL32t6XFQPA9gLTK3 X-Proofpoint-Spam-Details-Enc: AW1haW4tMjUxMjA0MDA1MCBTYWx0ZWRfX/ue7dBQJ1V4q A3xhqdantttadhPbB/PbQK1Km7p9f7Skw1rShdYeZ3tnnyK7idINbHpWwBfiCjUIA5vwxu6W6fF Db14qbOpUc/Z7qiq88JbaeAdb2SE6KXkqqta5cm8ec/WFA5nmJA6KHXAN2lVMerVqTVE8uoLsR/ JNYBvo9VW5C/ucjrbfHJl+7gnwPKc1sS6qlJLCEGbXDHvcE3DZGT+VokddHD/ef1WvkWdU2quyB L0OeugDI6DtQEMANNn6teOYeaRbcGYdgHQ0IxOktprpWBdQPF2tmdj71aQ4Y8+xKA8c5DnGvXeA JPSSm7SKgpWATiyPVRGuhnjsXzHGJzKEV3oXuILL8fD9TfOqd+Z7wIeckwU9olIDQ04Z4O670of RafGrblxpG5cpePTMvs0bnjlWkjmQA== X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1121,Hydra:6.1.9,FMLib:17.12.100.49 definitions=2025-12-04_01,2025-12-03_02,2025-10-01_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 impostorscore=0 malwarescore=0 spamscore=0 phishscore=0 suspectscore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 adultscore=0 priorityscore=1501 classifier=typeunknown authscore=0 authtc= authcc= route=outbound adjust=0 reason=mlx scancount=1 engine=8.22.0-2510240001 definitions=main-2512040050 Content-Type: text/plain; charset="utf-8" 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_mkwri= te()") Signed-off-by: Jianpeng Chang Reviewed-by: Huang Ying --- v3:=20 - Add the description about pte_mkdirty in commit message - Note that the redundant bit operations in commit message - Fix the comments following the suggestions v2: https://lore.kernel.org/all/20251202022707.2720933-1-jianpeng.chang.cn@= windriver.com/ - Use pte_mkwrite_novma(pte_mkdirty(pte)) instead of manual bit manipulat= ion - Updated comments to clarify pte_mkwrite_novma() alone cannot be used v1: https://lore.kernel.org/all/20251127034350.3600454-1-jianpeng.chang.cn@= windriver.com/ arch/arm64/mm/trans_pgd.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/arch/arm64/mm/trans_pgd.c b/arch/arm64/mm/trans_pgd.c index 18543b603c77..766883780d2a 100644 --- a/arch/arm64/mm/trans_pgd.c +++ b/arch/arm64/mm/trans_pgd.c @@ -40,8 +40,14 @@ static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, = unsigned long addr) * Resume will overwrite areas that may be marked * read only (code, rodata). Clear the RDONLY bit from * the temporary mappings we use during restore. + * + * For both kexec and hibernation, writable accesses are required + * for all pages in the linear map to copy over new kernel image. + * Hence mark these pages dirty first via pte_mkdirty() to ensure + * pte_mkwrite_novma() subsequently clears PTE_RDONLY - providing + * required write access for the pages. */ - __set_pte(dst_ptep, pte_mkwrite_novma(pte)); + __set_pte(dst_ptep, pte_mkwrite_novma(pte_mkdirty(pte))); } else if (!pte_none(pte)) { /* * debug_pagealloc will removed the PTE_VALID bit if @@ -57,7 +63,14 @@ static void _copy_pte(pte_t *dst_ptep, pte_t *src_ptep, = unsigned long addr) */ BUG_ON(!pfn_valid(pte_pfn(pte))); =20 - __set_pte(dst_ptep, pte_mkvalid(pte_mkwrite_novma(pte))); + /* + * For both kexec and hibernation, writable accesses are required + * for all pages in the linear map to copy over new kernel image. + * Hence mark these pages dirty first via pte_mkdirty() to ensure + * pte_mkwrite_novma() subsequently clears PTE_RDONLY - providing + * required write access for the pages. + */ + __set_pte(dst_ptep, pte_mkvalid(pte_mkwrite_novma(pte_mkdirty(pte)))); } } =20 --=20 2.52.0