From: Michael Ellerman <patch-notifications@ellerman.id.au>
To: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org,
Hari Bathini <hbathini@linux.ibm.com>,
npiggin@gmail.com
Cc: mahesh@linux.ibm.com, sourabhjain@linux.ibm.com,
kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v3 1/2] powerpc: handle kdump appropriately with crash_kexec_post_notifiers option
Date: Wed, 15 Dec 2021 11:24:42 +1100 [thread overview]
Message-ID: <163952788224.919625.4766990349365852809.b4-ty@ellerman.id.au> (raw)
In-Reply-To: <20211207103719.91117-1-hbathini@linux.ibm.com>
On Tue, 7 Dec 2021 16:07:18 +0530, Hari Bathini wrote:
> Kdump can be triggered after panic_notifers since commit f06e5153f4ae2
> ("kernel/panic.c: add "crash_kexec_post_notifiers" option for kdump
> after panic_notifers") introduced crash_kexec_post_notifiers option.
> But using this option would mean smp_send_stop(), that marks all other
> CPUs as offline, gets called before kdump is triggered. As a result,
> kdump routines fail to save other CPUs' registers. To fix this, kdump
> friendly crash_smp_send_stop() function was introduced with kernel
> commit 0ee59413c967 ("x86/panic: replace smp_send_stop() with kdump
> friendly version in panic path"). Override this kdump friendly weak
> function to handle crash_kexec_post_notifiers option appropriately
> on powerpc.
>
> [...]
Applied to powerpc/next.
[1/2] powerpc: handle kdump appropriately with crash_kexec_post_notifiers option
https://git.kernel.org/powerpc/c/219572d2fc4135b5ce65c735d881787d48b10e71
[2/2] ppc64/fadump: fix inaccurate CPU state info in vmcore generated with panic
https://git.kernel.org/powerpc/c/06e629c25daa519be620a8c17359ae8fc7a2e903
cheers
prev parent reply other threads:[~2021-12-15 0:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-07 10:37 [PATCH v3 1/2] powerpc: handle kdump appropriately with crash_kexec_post_notifiers option Hari Bathini
2021-12-07 10:37 ` [PATCH v3 2/2] ppc64/fadump: fix inaccurate CPU state info in vmcore generated with panic Hari Bathini
2021-12-15 0:24 ` Michael Ellerman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=163952788224.919625.4766990349365852809.b4-ty@ellerman.id.au \
--to=patch-notifications@ellerman.id.au \
--cc=hbathini@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=lkp@intel.com \
--cc=mahesh@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=npiggin@gmail.com \
--cc=sourabhjain@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.