From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f178.google.com (mail-qk1-f178.google.com [209.85.222.178]) (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 184E8428470 for ; Mon, 3 Aug 2026 19:42:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785786180; cv=none; b=Mzk6XgenmcgwHj9Y0HWw17Ns82MN4gTLc0y4VwQwv70GrF+K8ahfqkkarRSWiaF+ILg46WQbzEB8qHSgXnidIX6K7oDyEHAyysYCa547HEwhY4VutE4mz65L/ypRypmZc+gB4Es/gzB9m3F18qF2v9WxQT9mgxcZw55wN+VYgHE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785786180; c=relaxed/simple; bh=8P4WPxOTYGImqUUcIeBUdKh02DVYLKu8M/s85ThEmAM=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=iDof2c7ha7dQgQQ9zh2yF+BzdmIZfoqOg5cM8C+BSmgcFl1QNzqaqVH0D6+Nfpazd3uLU3ex7Ku46oS4ZsDjRgIty9URntj2ClMXF5F5Ywzxif8KAIgn+acutcpiVzgqyW8ViOx0s18FJHHznMZX7B3eqYsCdb9k5aiG2o9FCNU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hVvV2uZo; arc=none smtp.client-ip=209.85.222.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com 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="hVvV2uZo" Received: by mail-qk1-f178.google.com with SMTP id af79cd13be357-92ed3993c1eso194216085a.1 for ; Mon, 03 Aug 2026 12:42:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785786178; x=1786390978; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to:content-type; bh=rwuoYLIZuv5ApTNScLZwtjL2AQGWD4RWVJHiBkDbMFE=; b=hVvV2uZoBCVAh0kOoRixmWEWq0grvG0fuG1G5J06pOgrA8C1BiLP4limNhkJEWYNun 5wqmdKhP87NMFsW1W34r1G0s5F/QMB1EaTQWNEzyDzz0qN8ra7K1BDFOKDj4GaFznplq TN8Zurpcf9a7C6CKlE1ooMLeJo9pWjRGm61U1TMVL/4wWcqyfQYhJJ3vZvdMnhLBHkwO +lTeKGFLD212wXIyHfJBCcuLNe7zK/iGdFYXtDtaLJbyTP0yMDYFl69bnGLBo0ayiQKl 7qnBZnskeuj1bVIVlhcZylJIPsIZ0C/8IcjrTelqbwK+NP81HT3dns/C+R8HHW8wtm+v TpXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785786178; x=1786390978; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rwuoYLIZuv5ApTNScLZwtjL2AQGWD4RWVJHiBkDbMFE=; b=VuIEc270O52U3wl0w6SB81pXk0b8d2GkioSMZ9CumYbbKBU3ErHHNd+T4zJgiLk0FH RgZ1eyE/j5G8ar7tw67edPv92dvrXBiNFFq09RngU2e8HlskPStxaAdCCUSmsJHQU+iP kKUNvYB2dK+srdDEszaHkQQ4TGjb6Fke4duJozrX5yPgPLuz29wRnWtcW8DyCnsHWOKv hLZqL4J1ruh7Da9Gu/tZVYimkvmipkWGGM4f1vkzXa4hzMUlS4ndXxrxjhwziGudVTRe 6lwe4DxcrTLjHmukWQPadOsp4Ff3lqD4k/AubpGIZFJc30D1egie1WJ8tU0CDxR4VYnx EjPA== X-Forwarded-Encrypted: i=1; AHgh+Ro8Y7VkCQh0A7FB5o4Sh1fV5PFZvb4Cf3fvqqNFjz+/PTA+xhenP0FggaiME5ja56Q28tl5gMYprsIhjZQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxI9ehhyk4MhBZsX8/6w5oVOqkw9ERZcxcmDg/IPxoPtIhwm/Mu kyVzbeFObb6gnP0vEVhAPWCKt7MHxKUibq5Wy3/jqo5qAysQ95R2BstA X-Gm-Gg: AR+sD124V2ZOC9XPgzkvL/v81JUCmj4x/rBua54RqBDCCcwssGt9AzNLpBNbqB9eQ0c +hLhTjWgM5fXclU+61mHkhj6hr9ERwEJd7EqqxUALfdjvUHTrX/4kQAVoYZkE4x41exy5i5VyfS b+dQ0ib9FqacIpccPBUDjDx2d5wrKwe7Fby05qxxJM5TwU6q/AdVfNtseIumSVWDvRU7p6cPm0r vk6lTc6SE5V+roSmushJ1T/V+R5yxnW5VOI/rnYm90/1AsKqyl6kpWBlbmjfpmhXaS0FcLD+Xb1 PQjHBKf7EEmA6Dks8xourI3AQTIWnGalREcmpt/RnC8JW+srnx9ZdC1CbbJiHJyXphUixhjafyK 0YJMC2T4InSUHHCQMYxnwAhYjdDSRDqlbhEaPiOC4/pjpCc5vSH4U/3Mudg06IVH7czSl9ZVakl 2Uh+qw8AFsOBqqSYvNrt1cJUPLUWi9S0BMHT4g3pLUPYc1SqwoIFu2Yb9jl/kaa5MPnl2UGYC6S XNc1iCqFbo7Wwk4D2gUvcZyAbDZUhtWep38mVHCjD0lacviZ+JNjRCzH+1b0yymsxkSQ5WY X-Received: by 2002:a05:620a:284e:b0:92e:db1f:185c with SMTP id af79cd13be357-934a0aaee08mr2254503585a.43.1785786177782; Mon, 03 Aug 2026 12:42:57 -0700 (PDT) Received: from CW-D0XG2Q16P7-L (pool-173-68-111-115.nycmny.fios.verizon.net. [173.68.111.115]) by smtp.gmail.com with ESMTPSA id af79cd13be357-9349bc25410sm729451885a.7.2026.08.03.12.42.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Aug 2026 12:42:57 -0700 (PDT) From: Maxi Saparov To: Mike Rapoport , Pasha Tatashin , Pratyush Yadav Cc: Alexander Graf , Evangelos Petrongonas , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, sdimitropoulos@coreweave.com, Maxi Saparov , stable@vger.kernel.org Subject: [PATCH] kho: do not reserve scratch memory in the kdump kernel Date: Mon, 3 Aug 2026 15:39:38 -0400 Message-ID: <20260803193938.8778-1-maxi.saparov@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Maxi Saparov If a kernel with CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=y (or kho=on) does not receive a handover FDT, it reserves KHO scratch memory in kho_reserve_scratch(). The function computes the sizes from the early memblock reservations of the kernel. The default scratch_scale is 200%. The lowmem and global scratch areas each get twice the size of the early reservations. Each NUMA node gets one more scratch area at the same scale. The kdump kernel always takes this path. Since commit a6715d7ec472 ("kho: skip KHO for crash kernel"), the kernel does not add KHO metadata to the crash kimage. As a result, the kdump kernel never receives a handover FDT and always reserves scratch memory. The kdump kernel boots in the small crashkernel= memory reservation. On our x86 hosts, the kernel and initramfs make approximately 176 MB of early reservations. The scratch areas then use approximately 650 MB more of the crashkernel memory. When a large early allocation fails, the kdump kernel panics: bio: can't create integrity buf pool A kdump kernel has nothing to hand over: its only task is to dump the memory of the old kernel and reboot. Disable KHO in the kdump kernel so that it does not reserve scratch memory. Fixes: 3dc92c311498 ("kexec: add Kexec HandOver (KHO) generation helpers") Cc: stable@vger.kernel.org Signed-off-by: Maxi Saparov --- kernel/liveupdate/kexec_handover.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c index 6fad9152387a..53b59edb5b36 100644 --- a/kernel/liveupdate/kexec_handover.c +++ b/kernel/liveupdate/kexec_handover.c @@ -12,6 +12,7 @@ #include #include +#include #include #include #include @@ -1636,6 +1637,9 @@ void __init kho_memory_init(void) if (kho_mem_retrieve(kho_get_fdt())) kho_in.fdt_phys = 0; + } else if (is_kdump_kernel()) { + kho_enable = false; + pr_info("disabled in the kdump kernel\n"); } else { kho_reserve_scratch(); } base-commit: 3a0b8fa2eb36afc88b62a95f33f0c77c71fa5ded -- 2.55.0