lkml.org 
[lkml]   [2011]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [RFC][PATCH v3 2/3] Skip spin_locks in panic case and add WARN_ON()
Hi,

Thank you for coordinating discussion.

>Hitachi's whole goal behind
>kmsg_dump is to record every possible reason for rebooting the machine for
>inspection on reboot, I think if I understood Seiji privately.

Exactly.

>Now we have a scenario (though rare), where kmsg_dump can fail to save a
>dump because someone already has the lock.
>Seiji, has does this failure impact kmsg_dump's goal?

When we use EFI-enabled system, we can avoid this failure because
,as you can see below(spec of EFI 2.3), kernel in NMI can call set_variable
runtime service even if previous call is busy.

<snip>
7.1 Runtime Services Rules and Restrictions
7.1.1 Exception for Machine Check, INIT, and NMI.
.
.
.
If the OS determines that the Machine Check is non-recoverable, the OS level handler may
ignore the normal restrictions and may invoke the runtime services described in Table 31 even
in the case where a previous call was busy. The system firmware will honor the new runtime
service call(s) and the operation of the previous interrupted call is not guaranteed.
Any interrupted runtime functions will not be restarted.
The INIT and NMI events follow the same restrictions.
<snip>

So, next steps we should take are as follows.

- Fix efi_pstore so "efivars->lock" in efi_pstore_write() skips in panic path.

- Fix smp_send_stop() (or introduce new function call)
so that kmsg_dump(KMSG_DUMP_PANIC) is always called in NMI.

Currently, panicked cpu sends NMI to all cpus other than itself in smp_send_stop() (with Don's patch).
My suggestion is that panicked cpu sends NMI to itself and then it calls kmsg_dump(KMSG_DUMP_PANIC) in NMI.

Seiji


\
 
 \ /
  Last update: 2011-12-20 00:41    [W:0.841 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site