Re: [PATCH] kexec: Add --lite option

Hi James, On 08/12/2015:04:00:17 PM, James Morse wrote: > Hi Pratyush, > > On 07/12/15 14:07, Pratyush Anand wrote: > > On 07/12/2015:01:16:06 PM, James Morse wrote: > >> I haven't benchmarked this, but: > >> > >> util_lib/sha256.c contains calls out to memcpy(). > >> In your case 1, this will

Re: [PATCH v12 05/16] arm64: Add back cpu_reset routines

Hi Will, On Thu, 2015-12-03 at 09:32 +, Will Deacon wrote: > On Wed, Dec 02, 2015 at 02:57:30PM -0800, Geoff Levand wrote: > > On Mon, 2015-11-30 at 10:40 +, Marc Zyngier wrote: > > > > > All that can be solved in C, and mostly at compile time. Using an > > > assembler trampoline is

[V6 PATCH 2/6] panic/x86: Allow CPUs to save registers even if they are looping in NMI context

Currently, kdump_nmi_shootdown_cpus(), a subroutine of crash_kexec(), sends NMI IPI to non-panic CPUs to stop them and save their register information and doing some cleanups for crash dumping. However, if a non-panic CPU is infinitely looping in NMI context, we fail to save its register

[V6 PATCH 5/6] x86/nmi: Fix to save registers for crash dump on external NMI broadcast

Now, multiple CPUs can receive external NMI simultaneously by specifying "apic_extnmi=all" as an boot option. When we take a crash dump by using external NMI with this option, we fail to save register values into the crash dump. This happens as follows: CPU 0 CPU

[V6 PATCH 4/6] x86/apic: Introduce apic_extnmi boot option

This patch introduces new boot option, apic_extnmi: apic_extnmi={ bsp | all | none} The default value is "bsp" and this is the current behavior; only BSP receives external NMI. "all" allows external NMIs to be broadcast to all CPUs. This would raise the success rate of panic on NMI when BSP

[V6 PATCH 3/6] kexec: Fix race between panic() and crash_kexec() called directly

Currently, panic() and crash_kexec() can be called at the same time. For example (x86 case): CPU 0: oops_end() crash_kexec() mutex_trylock() // acquired nmi_shootdown_cpus() // stop other CPUs CPU 1: panic() crash_kexec() mutex_trylock() // failed to acquire

[V6 PATCH 6/6] Documentation: Add documentation for kernel.panic_on_io_nmi sysctl

kernel.panic_on_io_nmi sysctl was introduced by commit 5211a242d0cb ("x86: Add sysctl to allow panic on IOCK NMI error"), but its documentation is missing. So, add it. V6: - Newly added Signed-off-by: Hidehiro Kawai Cc: Jonathan Corbet Cc: Andrew

[V6 PATCH 0/6] Fix race issues among panic, NMI and crash_kexec

When an HA clustering software or administrator detects unresponsiveness of a host, they issue an NMI to the host to completely stop current works and take a crash dump. If the kernel has already panicked or is capturing a crash dump at that time, further NMI can cause a crash dump failure.

[V6 PATCH 1/6] panic/x86: Fix re-entrance problem due to panic on NMI

If panic on NMI happens just after panic() on the same CPU, panic() is recursively called. As the result, it stalls after failing to acquire panic_lock. To avoid this problem, don't call panic() in NMI context if we've already entered panic(). V6: - Add a comment about panic_cpu - Replace the

RE: Re: [V6 PATCH 5/6] x86/nmi: Fix to save registers for crash dump on external NMI broadcast

iro, > > [auto build test ERROR on v4.4-rc4] > [also build test ERROR on next-20151209] > [cannot apply to tip/x86/core] > > url: > https://github.com/0day-ci/linux/commits/Hidehiro-Kawai/Fix-race-issues-among-panic-NMI-and-crash_kexec/20151210-095 > 254 > config: x86_64-randc

[V6.1 PATCH 5/6] x86/nmi: Fix to save registers for crash dump on external NMI broadcast

Now, multiple CPUs can receive external NMI simultaneously by specifying "apic_extnmi=all" as an boot option. When we take a crash dump by using external NMI with this option, we fail to save register values into the crash dump. This happens as follows: CPU 0 CPU