From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) (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 473CF19ADA4 for ; Fri, 17 Jul 2026 12:56:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784292981; cv=none; b=dhhXz0olXSuMZoZ5wZXAoojzFWoubvyjK3pj3IeLORDt5fVU7u3jqqsHir2EyeJ9i8jRwnB3V7qHqnCPwteyeEcYS0EBzuUv46z1EQkKln6kyVrOWWtPazX4UhmBNkKLoBRvQsw8yYhGzLPp8cbbRR3j7BeJ1o2NgsW636OiVLg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784292981; c=relaxed/simple; bh=MqkWjN+wXCgO432QBhi8dNY1Jv9RZnWOA46egm7Pq4A=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SVmXTRhLmnl04Sd64+3kaVx1NGYc5JbmUjWQ0kRCYY528FbkjX9tR4/MGNUK62XJfVgK37/ELz5prPJNmCkxTfXEEEf9j/k0fDT5YUNJYZDY9Bky38Owb9JSesQ84/TtwGI9OyArl9NZFWmisfNz07+B8BhfXtXp71Sflgi4vEo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=J+g0Vu61; arc=none smtp.client-ip=209.85.128.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="J+g0Vu61" Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4954c9f380bso2376775e9.0 for ; Fri, 17 Jul 2026 05:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1784292978; x=1784897778; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=uFzfVcYgDKfNQdQttDIrXNQpy6cqxkNgJR+Y4zG6BXU=; b=J+g0Vu61Gc8Gcz+cf7XSQM3dVPb0280zDlo71kSMHS4Z3jCMLj8COvPK822Yc7ejtc QQBKsf9ga4TcHy6fswvai//2g3O5LAzQDRQaggEeh7B4BPopoZRFZgrFbI/R/suGC5LF B17xD7nHRKzJnfTlrWkqURwT98LpXynghR6wd45JMKKJrJnedMzZcMM/kX6QEtEGZqlq BVTad/P1a2q4VZhf+jygZwCTBSy1IkwPdaH6GoT0W8Zj0UzpB/eCxe3XUR9nqqWcSE+C NuwaWiL8RP67wJ9uI8ooxlEdLDFt6cMa+F8VR8CXE7QZuQL9E3Gcwnwx0cwCU9Hf+yfA 9WDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784292978; x=1784897778; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=uFzfVcYgDKfNQdQttDIrXNQpy6cqxkNgJR+Y4zG6BXU=; b=fSljDH/PKv++7+/mLfgi+PddEYA06YTXiWzHLcC0u/O0EM04FpyAgQ+yppT5buwJkG c4XU+97I3dd63VbLqjDm2+rbq17zNasAig0W5Xs7X1JU12Bf+3rOO9nqbd8vQ7300CcN J8Y+tP767WEfqYdIissDeFhu35IVuHr501Ho56njP9FOLp56bh7RzjnSJ2fFTtVa5t4C EQ3Wdepe7xoQvlwwMe3OkRRvYBuUGM7ZWccHhsb1q7LU8tpoq1MOzDcZgxL+rOYM2MUZ NK+rprNz99bgqPemLiUGmaTVXQbloi9/Na9XKta1iDQa9M3+L1ISCJvG5fk9zG0lAZ9T egeg== X-Forwarded-Encrypted: i=1; AHgh+RoJVxqWOxS1IX30r64XOngcUiXTfzKGG2XWwn2xZwM4AXn9ROjCvGhgPTmXbb8bimIqMlBqUDvZCuDBh2A=@vger.kernel.org X-Gm-Message-State: AOJu0YybLgeBc5vnh8aQWQqtsn0F//mWcGP4wrPzgHLgHf1WOh05ygHJ NNVThFDK9SJTO9zVXZ7HUYEWElIA32Up8Buvp8df8fQ6mOUnegH0oEZL351Fnqv0WQE= X-Gm-Gg: AfdE7cmLkpBMvFxCmYn6dNEudIq6syH9scv2pmA08M4XeZVjMzxb6XRGUx8/impQQw0 RRtsPfg28skrfvWlp3xP/7d48ymyqPTy0DPivQPypT+gOSY4Rvbf5baLTMOd5ijfVMDo7CHUG0z k89LFk98E7TPVy2/gCgu0DbDQL6r4Ihd/6MJQA3GDDIAE3ACya4VWS+BfQtJvELpPRZakd3QvtJ 7DTFQ0bPGW+nf4GzmcoNNw+j20pCZXubjJ451stRCaDClA87lsdZc6HdudQjL36XhUBDIjRBAYL HkSZsQlerqxfc86mu8xsgle+r0KAsdzMB0bxU+wffiKIbD7JuhBmQK5GQ4ngkwpJq4qt11EPKCD 3Y1xpogjqQfVlLWRbo19Zhr2DzQFHsPo02qBuQgbji1LaLeL2PSNumqzFuMQprZlEhZT8Zl//K0 vQbL3c X-Received: by 2002:a05:600c:4ec6:b0:495:4d5c:903e with SMTP id 5b1f17b1804b1-4954d5c913dmr9006345e9.7.1784292978424; Fri, 17 Jul 2026 05:56:18 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4954a2eddb8sm95667855e9.14.2026.07.17.05.56.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Jul 2026 05:56:18 -0700 (PDT) Date: Fri, 17 Jul 2026 14:56:15 +0200 From: Petr Mladek To: Bradley Morgan Cc: akpm@linux-foundation.org, baoquan.he@linux.dev, 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 Subject: Re: [RFC PATCH 0/4] panic: a pre kdump notifier list for hypervisor upcalls Message-ID: References: <20260711002253.1115-1-include@grrlz.net> 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: <20260711002253.1115-1-include@grrlz.net> On Sat 2026-07-11 00:22:49, Bradley Morgan wrote: > 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. IMHO, it is not about speed at all. The main criteria are: + what has to be done at which stage + reliability I see that there are 4 situations where crash_kexec_post_notifiers is set to true: $> git grep "crash_kexec_post_notifiers = true" arch/powerpc/kernel/fadump.c: crash_kexec_post_notifiers = true; arch/x86/hyperv/hv_crash.c: crash_kexec_post_notifiers = true; arch/x86/virt/svm/sev.c: crash_kexec_post_notifiers = true; drivers/hv/hv_common.c: crash_kexec_post_notifiers = true; IMHO, these point to the notifiers have to be called before kdump because otherwise something goes wrong. The rest are users who do not care. They have happily worked as post-kdump notifiers for years. > 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, This is required by any code called in panic(). It is not special to the pre-kdump notifiers. > other CPUs may still be running Good question. My upderstanding is that people prefer when kdump catches the system when all CPUs are still running. But it also complicates any lockless solution in the notifiers. > and it has > to tolerate being entered again if the panic path itself panics. The panic-in-panic is a dark corner for me. I believe that it might happen but I have never met it. And any panic() code should do its best to avoid it in the first place. By other words, panic-in-panic is a corner case. We should not focus on it too much. > 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. I am not sure if I got it correctly. IMHO, the ultimate plan should be to remove the "crash_kexec_post_notifiers" option. It is a black magic. Someone has to set it because otherwise crashdump does not work. Others disable it because it breaks or might break crashdump. Alternative solution would be to move the potentially dangerous notifiers to some optional list, aka, panic_extra_debug_notifiers. > 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. I am fine with moving one notifier by one. But we first need to make sure that the split, ordering, and naming makes sense. The good thing about Piccoli's patchset was that we saw the whole picture. And I believe that we need the whole picture to make a reasonable move here. > One alternative is splitting the legacy list by priority and calling the > high priority half before the crash kexec. I personally prefer two or more notifier lists. Different lists make it clear that they are proceed at different stages. The names might even help to decide which list is the right one. The priority is much harder to maintain. Best Regards, Petr