From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pf1-f180.google.com (mail-pf1-f180.google.com [209.85.210.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D36B219DF4D for ; Thu, 12 Feb 2026 18:51:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770922310; cv=none; b=KN9fLjYlhO7iGfUw7RZThzIGLJWi7d5rvw5hUb3xi+y12rNjtoD+Ru5Nqxpx4/rjFOH7zKMzv9W3zBjtfgGjxry2qW5M3lPFxJfVsv7/zLtsUGLBZoRjCMz5diIYABzL9ZmQUaC+3SfnE+89nd+QqjiIrDd2Ldi0fhZNx6FmR1U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770922310; c=relaxed/simple; bh=qBliPaQ/Bkb/gQ6p2NBmV3pde26aUORLaxSMjA2Iags=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YkAgdyuaCLOoQUi8Xkk525b6Rz0Soc+v2X1XJDLtutZmyQM8enZnMeeqWQ4t5ZZAVi3i7Vl7KrkWTsoBz/c2Qf8USY7Ha7REXeOT5CR6nhglpfs1Vpc2M01B1QDCffMpXpVhUw/mCu42oZq9OKo/efW9NOmkRp05UfANo0fRzLo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=H/g2eys9; arc=none smtp.client-ip=209.85.210.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=roeck-us.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="H/g2eys9" Received: by mail-pf1-f180.google.com with SMTP id d2e1a72fcca58-824a3509a12so108066b3a.2 for ; Thu, 12 Feb 2026 10:51:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770922308; x=1771527108; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=GSugxaTjAF+Vtu15k1dzpbbnjPb77R/eFUqciQ+Hpeo=; b=H/g2eys97sAekZoIlDQws9BOxPzouF0C/wjqhc07OY5E2VeiwD1dpzsbzaK+NBmTqT P6a6YOIz8KNCoHZj1ukVHILT6haMst+7XNJv1J6GEr6O0rNVa3HbPg6Oc3/j/lHEB1sv IAtHpoPDsKjAFESzWFxt1fE7idssugzcsVJ2oTvC6N4OLVTpzWUD43v1ZVRK0yypMHbm xCYCOEwUJ5CzBPLK7IR7a7ZfsSi6hsKWBALpIlnEza3du2j3pG0yBGbH+J1vxqOS1/6v kxa05wUUmsl3bnd8xlM2kEz5KYSWUwtSOcx2Auh+eMR6JpZdTb/x66xCQ+8Sb1/XrbHJ oKdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770922308; x=1771527108; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-gg:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=GSugxaTjAF+Vtu15k1dzpbbnjPb77R/eFUqciQ+Hpeo=; b=NGLYs1oGtZjAYSksmjEqWe3R4InmACTzWE6194nxjbVM19KSfBDH0kBAi0Xk9hrNGw TGtvntPTwx4l24U0Y+DXPgiQvxl2uy9esA6H5SqTsf3FGSoBQgQxF6By2sNl2cfF9coZ +lr81XyrVRMbFRGFT8T2zme82LcSqLceRfXdsWUXd1Oc1ezReUL2FhGsX/lWaF8LEpUB z/WcBROY7uKwuS2MsnXaY70tiVuVZ/XDu9xJsGC8p97qHtvHZ+/wo/DLZ7D6is6oJ88/ dVH89fDvD1YSlnHnLORVigocXTgvDnBd3go2bIVlHVlIjtFUeGiGhPvOSYJk7oAfwqvK n3dw== X-Forwarded-Encrypted: i=1; AJvYcCVZLfAfkAkhs8Yl68xUxS0gJw804lyd92zCoaCNLCBGOCaXnOPVdwCa3Chjg7u6QVR6jHdrGsqkQw/XQPA=@vger.kernel.org X-Gm-Message-State: AOJu0Yyw6BZ+8Hlm6r+5X7nLDmUUIKWWHwmLOSKedob/r43XsAz9Qupk DVkETl2py4oSv/0kdXxEYcrYj4doGJyvrqH4pboSbxivp/UaFG5iwa6a X-Gm-Gg: AZuq6aIxvu3ivtnW7Q0Bsz1EMYPq8a4mhKGZqHbEcCTcMZyyl0J9Z4MAJH0kjbS8xc4 66oRZKwTQAulA6KIBaI8w1IhrhAvFrFuim4cKntl0WVl2OENzSjRl1bMX0IinNjUiJu8ymIXYO0 EJuQzAs1vpIAVXxwTyl+ee6VKdxZJucH1a51xT+pSnXYBjoV22OLrExvkalfEVJIX0WHFnYSybO cHYhCxLzp0QI2DOZKVjW5LfimLW0PMsiHX40VFdG2UxSpvjcE/hQPnDgSaUKZau47Aj6Ix0lFJ4 q4rfq7hLwy/8ab96qGVlItGvIPtv8w8VrlAQvz2fLoiAEAXv2q9P+XAQDbpqb7RnOl/U5weHdYY fJFT/QBLorivJlzEXX1mCaPSX1w7jKEVWZPBB2P5yhz0pfoQn7qgdszq4YyQwVlXLF1IAEenPSA 0IkP1IsH70XMke6gxVggxYdKlKc0UEJT7GZKVR X-Received: by 2002:a05:6a20:7290:b0:38e:9ebe:525e with SMTP id adf61e73a8af0-3944cf5c9abmr3161888637.52.1770922308181; Thu, 12 Feb 2026 10:51:48 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:da43:aeff:fecc:bfd5]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c6e197f8bc7sm5318260a12.29.2026.02.12.10.51.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Feb 2026 10:51:47 -0800 (PST) Sender: Guenter Roeck Date: Thu, 12 Feb 2026 10:51:45 -0800 From: Guenter Roeck To: Jianpeng Chang Cc: catalin.marinas@arm.com, will@kernel.org, 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: <73e9c019-abd8-4914-a70a-277142e4f306@roeck-us.net> References: <20251204062722.3367201-1-jianpeng.chang.cn@windriver.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: <20251204062722.3367201-1-jianpeng.chang.cn@windriver.com> Hi, 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 ? Thanks, Guenter