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 0B2C92609D6; Tue, 4 Nov 2025 02:59:00 +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=1762225141; cv=none; b=aBrfBL4EwgyUKBOCJpsr00NxYyVeRfJBiAZteYHBAdRRCmxe4dXUNjdi2P574mVY8Jz4uQRnzwBHsoGPMNmIGGS01uxjS+BrMvgq1PUQAxL9r+bZYExy6z4/t3oUxcjhufiC0+l+RYdzlu7OW6dpFjKwcltp5ATKzaWgr4nh5nM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1762225141; c=relaxed/simple; bh=IcOuYlJB53idZbAmddJQli+QJwDAwzfIs89z8rhSVRY=; h=Date:To:From:Subject:Message-Id; b=lllAZIGImPcSCtyEyRD7R2QuTC+0IOan2XqdEWHQFKiDBCAlmyl7or0RD7tfTPDWTvyxinXA77yCrki1BJES5UTr//bGpJYcXgmFDZcj1UThpqysWX25mbaHciuMuRsXSuB8+NWnTnGp1Y20xWlJedsoDaXsTyXE36sCIJlitbs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=z+GxhirF; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="z+GxhirF" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 79A2BC113D0; Tue, 4 Nov 2025 02:59:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1762225140; bh=IcOuYlJB53idZbAmddJQli+QJwDAwzfIs89z8rhSVRY=; h=Date:To:From:Subject:From; b=z+GxhirFTTC95O3OF8pYhH4jCaUR/9c7lWvDF6WOnL/IagqSGcP/mNa2bkYHgSgQt n/jJIlWAfFoliQ88w4Xm0mqFks7DQrhZpT3iRYhknZJHoV4rkkXZwujhV1rqBESbPD P2zIeO6rKG8slthm81jx6V/G6arN748s7cxGxieo= Date: Mon, 03 Nov 2025 18:58:59 -0800 To: mm-commits@vger.kernel.org,thunder.leizhen@huawei.com,stable@vger.kernel.org,bhe@redhat.com,sourabhjain@linux.ibm.com,akpm@linux-foundation.org From: Andrew Morton Subject: + crash-fix-crashkernel-resource-shrink.patch added to mm-hotfixes-unstable branch Message-Id: <20251104025900.79A2BC113D0@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: crash: fix crashkernel resource shrink has been added to the -mm mm-hotfixes-unstable branch. Its filename is crash-fix-crashkernel-resource-shrink.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/crash-fix-crashkernel-resource-shrink.patch This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Sourabh Jain Subject: crash: fix crashkernel resource shrink Date: Sun, 2 Nov 2025 01:07:41 +0530 When crashkernel is configured with a high reservation, shrinking its value below the low crashkernel reservation causes two issues: 1. Invalid crashkernel resource objects 2. Kernel crash if crashkernel shrinking is done twice For example, with crashkernel=200M,high, the kernel reserves 200MB of high memory and some default low memory (say 256MB). The reservation appears as: cat /proc/iomem | grep -i crash af000000-beffffff : Crash kernel 433000000-43f7fffff : Crash kernel If crashkernel is then shrunk to 50MB (echo 52428800 > /sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved: af000000-beffffff : Crash kernel Instead, it should show 50MB: af000000-b21fffff : Crash kernel Further shrinking crashkernel to 40MB causes a kernel crash with the following trace (x86): BUG: kernel NULL pointer dereference, address: 0000000000000038 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI Call Trace: ? __die_body.cold+0x19/0x27 ? page_fault_oops+0x15a/0x2f0 ? search_module_extables+0x19/0x60 ? search_bpf_extables+0x5f/0x80 ? exc_page_fault+0x7e/0x180 ? asm_exc_page_fault+0x26/0x30 ? __release_resource+0xd/0xb0 release_resource+0x26/0x40 __crash_shrink_memory+0xe5/0x110 crash_shrink_memory+0x12a/0x190 kexec_crash_size_store+0x41/0x80 kernfs_fop_write_iter+0x141/0x1f0 vfs_write+0x294/0x460 ksys_write+0x6d/0xf0 This happens because __crash_shrink_memory()/kernel/crash_core.c incorrectly updates the crashk_res resource object even when crashk_low_res should be updated. Fix this by ensuring the correct crashkernel resource object is updated when shrinking crashkernel memory. Link: https://lkml.kernel.org/r/20251101193741.289252-1-sourabhjain@linux.ibm.com Fixes: 16c6006af4d4 ("kexec: enable kexec_crash_size to support two crash kernel regions") Signed-off-by: Sourabh Jain Acked-by: Baoquan He Cc: Zhen Lei Cc: Signed-off-by: Andrew Morton --- kernel/crash_core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/crash_core.c~crash-fix-crashkernel-resource-shrink +++ a/kernel/crash_core.c @@ -373,7 +373,7 @@ static int __crash_shrink_memory(struct old_res->start = 0; old_res->end = 0; } else { - crashk_res.end = ram_res->start - 1; + old_res->end = ram_res->start - 1; } crash_free_reserved_phys_range(ram_res->start, ram_res->end); _ Patches currently in -mm which might be from sourabhjain@linux.ibm.com are crash-fix-crashkernel-resource-shrink.patch crash-let-architecture-decide-crash-memory-export-to-iomem_resource.patch