From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from confino.investici.org (confino.investici.org [93.190.126.19]) (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 739B528690 for ; Sat, 11 Jul 2026 00:23:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=93.190.126.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783729384; cv=none; b=nLkvyGnyj92o0gJkNTI/wWW0gR7+3QOcQDMOWTNXOnvPX5HnORXAqo/KyM++ng14c81/MSbnah1TD0x5sZzdTZWAg5nFuOMrKnBE4iJOes5CzQcatZ7iXFaS7HbRT/uNvkKp1dRC6bHBeLKgOnKcUjVG7sqrA4hUUnwT4R0ZeQQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783729384; c=relaxed/simple; bh=4qZ2eTGRszJgC/rfm0iyWvz4mwh1mL907Aj4A/L102A=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=ni6PZAj/usPHeE+oEgCu24aMsxtlCLOlgQnYqpndlTt7dhJOZmcZkeH3FILBu2BCXS2SUtgo2+Y7mPpGMAAJe/I0qebc4f1+jPXkrjo2G4vHtwgNE9+8qBAXC62zFcGpQSvIjHqVya7lOw4Dz4dZwNWzTAxrruaeV2/T4aSWjag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=grrlz.net; spf=pass smtp.mailfrom=grrlz.net; dkim=pass (1024-bit key) header.d=grrlz.net header.i=@grrlz.net header.b=HSRuhDEW; arc=none smtp.client-ip=93.190.126.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=grrlz.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=grrlz.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=grrlz.net header.i=@grrlz.net header.b="HSRuhDEW" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=grrlz.net; s=stigmate; t=1783729372; bh=cRWIfNssA7u1GORCvVdy33O3ebBCpe8ieQd8Nngqvvc=; h=From:To:Cc:Subject:Date:From; b=HSRuhDEW021iisa8zsueE8fi/EGpG6y41y/Ax7D0xw/9F0+uM+JPdW1MhEwSLWo9b enLQHflJJqNZg7kx1yOIhp85MIiZuT8gA05CY5AHLmI+CPa7WV0yNAZQGhXH13nugL sGyjToZRMVTf5uK07ZzNLTGV8J9q1n2ehEW9XIys= Received: from mx1.investici.org (unknown [127.0.0.1]) by confino.investici.org (Postfix) with ESMTP id 4gxqCw6tzjz114C; Sat, 11 Jul 2026 00:22:52 +0000 (UTC) Received: by mx1.investici.org (Postfix) id 4gxqCw171tz113X; Sat, 11 Jul 2026 00:22:52 +0000 (UTC) From: Bradley Morgan To: akpm@linux-foundation.org Cc: baoquan.he@linux.dev, pmladek@suse.com, feng.tang@linux.alibaba.com, gregkh@linuxfoundation.org, arnd@arndb.de, corbet@lwn.net, rdunlap@infradead.org, gpiccoli@igalia.com, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, include@grrlz.net Subject: [RFC PATCH 0/4] panic: a pre kdump notifier list for hypervisor upcalls Date: Sat, 11 Jul 2026 00:22:49 +0000 Message-ID: <20260711002253.1115-1-include@grrlz.net> X-Mailer: git-send-email 2.53.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 When a crash kernel is loaded, panic() jumps to it before the panic notifiers run, unless crash_kexec_post_notifiers is set. So the hypervisor or firmware never finds out the guest panicked. Hyper-V doesn't get the crash registers, gsmi drops its firmware log entry, pvpanic stays silent, SEV-SNP skips its firmware and IOMMU shutdown. Whatever's watching the machine, the host, the BMC, fleet, sees a clean reboot instead of a crash. The only way around it today is crash_kexec_post_notifiers, but that runs the whole legacy notifier list before the kdump. That list has slow callbacks in it, IPMI being the obvious one since it talks to a BMC, so turning it on slows down every crash dump on the box. Hyper-V turns it on anyway and eats the cost for one callback. SNP did the same. This adds a separate list that runs before the crash kexec no matter what. Callbacks on it have to follow a contract: no locks, no allocation, no sleeping, other CPUs may still be running, and it has to tolerate being entered again if the panic path itself panics. The list head is private and you register through a function, because that's how you make people follow the contract. Priorities order it like any notifier chain. It lives in its own file because it's not panic code, just a notifier chain vpanic() calls once, and the custom walk it needs doesn't belong in the generic notifier API either. A separate file is also the only thing a MAINTAINERS entry can scope a reviewer to. Running anything before the crash kexec is a reliability trade. If an upcall hangs or faults and costs the dump, you want to know which one did it, so the notify path walks the chain itself and prints each callback's name on the console before calling it. Return values are ignored. A nested panic picks up the walk after the callback that was running, instead of re-faulting on it. This is the minimum: the list, the hook in the panic path, one driver converted so there's a real user, and the MAINTAINERS entry. pvpanic is the first one. Its callback is a self contained upcall that already takes its lock as a trylock, so it fits the contract as is. The rest (Hyper-V, Xen, gsmi, SNP) come in a follow on series. gsmi needs a rework to a trylock because its old deadlock guard assumed the other CPUs were stopped, which isn't true on this list. Once SNP's notifier is on the new list, the crash_kexec_post_notifiers forcing in snp_rmptable_init() goes away and SNP gets the early crash kexec back. Hyper-V keeps its forcing for now because its kmsg dump pass also needs to run before kdump. The register report just doesn't depend on it anymore. IPMI stays out. Its panic handling assumes the other CPUs have been stopped, and poking a BMC before the crash kexec would slow down every kdump on any box with a BMC. It stays on the legacy list, where kdump skips it like before. The legacy list, its position in the panic path and crash_kexec_post_notifiers itself are untouched, so the remaining registrants see zero change and nothing is renamed. This is on purpose. Piccoli's 2022 series tried to classify every panic notifier and the list split didn't go in. This does the one piece that fixes the kdump versus hypervisor conflict and stops. One alternative is splitting the legacy list by priority and calling the high priority half before the crash kexec. That can't do what this list does. The walk prints each callback's name on the console before it runs, and it ignores return values. atomic_notifier_call_chain can't do either. It honors NOTIFY_STOP_MASK, so one callback can halt the pass and lose every upcall after it. The walk also resumes past the faulting callback on a nested panic and runs under RCU instead of the atomic spinlock. Getting this behavior under a priority split means pushing a custom walk into the generic notifier API, which is more invasive than a file. Build tested on arm64. Bradley Morgan (4): panic: add a pre kdump notifier list panic: run the pre kdump list before crash kexec misc/pvpanic: notify the host on the pre kdump list MAINTAINERS: add an entry for the pre kdump notifier list Documentation/admin-guide/kernel-parameters.txt | 3 ++ MAINTAINERS | 6 +++ drivers/misc/pvpanic/pvpanic.c | 5 +- include/linux/panic_notifier.h | 18 +++++++ kernel/Makefile | 2 +- kernel/panic.c | 7 +++ kernel/panic_notifiers.c | 65 +++++++++++++++++++++++++ 7 files changed, 102 insertions(+), 4 deletions(-) create mode 100644 kernel/panic_notifiers.c -- 2.53.0