t; have already been stopped and register states have already been saved.
Ah, nice! I like this idea :)
>
> IOW, is there a reason that we can't get rid of smp_send_stop() and
> use the mechanism crash_kexec() is using to stop cpus after panic()?
own broken so let's
>> just revert the fool thing.
>
> Masami, you introduced this option. Are you fine with the revert? Is it
> really being used and tested?
Actually, it is tested but under very limited situation. I think we
need a clear acceptance criteria, IOW, we need a
e more appropriate
>> in keeping with things like 'panic_on_oops' or 'panic_on_stackoverflow'.
>
> I like it a lot better that way too :) I'm changing it to panic_on_warn
> unless
> anyone has any strenuous objections.
>
> P.
>
>>
>&g
f kexec_should_crash().
>
Thank you for fixing this issue :)
Reviewed-by: Masami Hiramatsu
I think this is fundamentally needed, because crash_kexec (a.k.a.
kdump) is mainly for shooting bugs which cause kernel panic.
Thus, to avoid the scenario that something went wrong on kernel
panic and fai
ment in kexec_should_crash() to explain not obvious
>>> things on this patch.
>>>
>>> Signed-off-by: HATAYAMA Daisuke
>>> Acked-by: Baoquan He
>>> Tested-by: Hidehiro Kawai
>>> Reviewed-by: Masami Hiramatsu
>>> ---
>>> include/
> might be saving dump.
>
> - And saving kernel logs to non volatile store.
>
> There might be more and I might not be aware about these. Hatayama and
> Masami, can you shed more light on this.
Yes, as I described above, we'd like to use IPMI to
den ==> overridden
> asynchonous ==> asynchronous
> accumalate ==> accumulate
> syncrhonized ==> synchronized
> therefor ==> therefore
> ther ==> their
> capabilites ==> capabilities
> lentgh ==> length
> watchog ==> watchdog
> assing ==> assign
>
On Sat, 29 May 2021 19:03:02 +0800
Zhen Lei wrote:
> Fix some spelling mistakes in comments:
> decrese ==> decrease
> immmediately ==> immediately
This looks good to me.
Acked-by: Masami Hiramatsu
Thanks!
>
> Signed-off-by: Zhen Lei
> ---
> include/linux/
you and Petr, seveal pitfalls have been
> pointed out and avoided.
>
> Meanwhile, I would suggest Masa and HATAYAMA to help give input about
> panic_notifier usage and refactory. AFAIK, they contributed code and use
> panic_notifier in their product or environment a lot, that will be very
> helpful to get the first hand information from them.
>
> Hi Masa, HATAYANA,
>
> Any comment on this? (Please ignore this if it's not in your care.)
No, that looks good idea to me. BTW, the 'dump' in the new notifieers
means both kmsg_dump and crash dump, right?
Thank you,
--
Masami Hiramatsu
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
