Groups > linux.kernel > #1232738 > unrolled thread

[V4 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec

Started by	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
First post	2015-09-25 14:10 +0200
Last post	2015-10-01 03:50 +0200
Articles	20 on this page of 28 — 5 participants

Back to article view | Back to linux.kernel

  [V4 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> - 2015-09-25 14:10 +0200
    [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec()  called directly Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> - 2015-09-25 14:10 +0200
      Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec()  called directly kbuild test robot <lkp@intel.com> - 2015-09-28 06:10 +0200
        RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and  crash_kexec() called directly 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-09-28 06:50 +0200
      RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and  crash_kexec() called directly 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-09-28 09:10 +0200
        Re: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and  crash_kexec() called directly Peter Zijlstra <peterz@infradead.org> - 2015-09-30 14:00 +0200
          RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and  crash_kexec() called directly 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-01 04:10 +0200
    [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on  NMI Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> - 2015-09-25 14:10 +0200
      RE: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic  on NMI 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-09-25 14:20 +0200
        Re: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic  on NMI Peter Zijlstra <peterz@infradead.org> - 2015-09-30 13:30 +0200
          RE: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic  on NMI 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-01 03:10 +0200
    [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> - 2015-09-25 14:10 +0200
      Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Peter Zijlstra <peterz@infradead.org> - 2015-09-30 14:00 +0200
        RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-01 04:40 +0200
          Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Peter Zijlstra <peterz@infradead.org> - 2015-10-01 08:30 +0200
            RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-01 09:10 +0200
              Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Borislav Petkov <bp@alien8.de> - 2015-10-01 10:50 +0200
                RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-01 12:30 +0200
                  Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Borislav Petkov <bp@alien8.de> - 2015-10-01 13:10 +0200
                    RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-02 03:00 +0200
                      Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Borislav Petkov <bp@alien8.de> - 2015-10-02 09:50 +0200
                        RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-05 04:10 +0200
                          Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Borislav Petkov <bp@alien8.de> - 2015-10-05 10:30 +0200
                            RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-05 11:30 +0200
                              Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option Borislav Petkov <bp@alien8.de> - 2015-10-05 12:20 +0200
    [V4 PATCH 2/4] panic/x86: Allow cpus to save registers even if they  are looping in NMI context Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> - 2015-09-25 14:10 +0200
      Re: [V4 PATCH 2/4] panic/x86: Allow cpus to save registers even if  they are looping in NMI context Peter Zijlstra <peterz@infradead.org> - 2015-09-30 14:00 +0200
        RE: [V4 PATCH 2/4] panic/x86: Allow cpus to save registers even if  they are looping in NMI context 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-10-01 03:50 +0200

Page 1 of 2 [1] 2 Next page →

#1232738 — [V4 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec

From	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Date	2015-09-25 14:10 +0200
Subject	[V4 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec
Message-ID	<qczZ7-T1-7@gated-at.bofh.it>

When an HA clustering software or administrator detects unresponsivenes
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.

Also, crash_kexec() called from oops context and panic() can
cause race conditions.

To solve these issues, this patch set does following things:

- Don't call panic() on NMI if the kernel has already panicked
- Extend exclusion control currently done by panic_lock to crash_kexec
- Introduce "noextnmi" boot option which masks external NMI at the
  boot time (supported only for x86)

This patch set can be applied to current -tip tree.

V4:
- Improve comments and descriptions (PATCH 1/4 to 3/4)
- Use new __crash_kexec(), no exclusion check version of crash_kexec(),
  instead of checking if panic_cpu is the current cpu or not
  (PATCH 3/4)

V3: https://lkml.org/lkml/2015/8/6/39
- Introduce nmi_panic() macro to reduce code duplication
- In the case of panic on NMI, don't return from NMI handlers
  if another cpu already panicked

V2: https://lkml.org/lkml/2015/7/27/31
- Use atomic_cmpxchg() instead of current spin_trylock() to exclude
  concurrent accesses to panic() and crash_kexec()
- Don't introduce no-lock version of panic() and crash_kexec()

V1: https://lkml.org/lkml/2015/7/22/81

---

Hidehiro Kawai (4):
      panic/x86: Fix re-entrance problem due to panic on NMI
      panic/x86: Allow cpus to save registers even if they are looping in NMI context
      kexec: Fix race between panic() and crash_kexec() called directly
      x86/apic: Introduce noextnmi boot option


 Documentation/kernel-parameters.txt |    4 ++++
 arch/x86/kernel/apic/apic.c         |   17 ++++++++++++++++-
 arch/x86/kernel/nmi.c               |   16 ++++++++++++----
 arch/x86/kernel/reboot.c            |   11 +++++++++++
 include/linux/kernel.h              |   21 +++++++++++++++++++++
 include/linux/kexec.h               |    1 +
 kernel/kexec_core.c                 |   26 +++++++++++++++++++++++++-
 kernel/panic.c                      |   29 ++++++++++++++++++++++++-----
 kernel/watchdog.c                   |    5 +++--
 9 files changed, 117 insertions(+), 13 deletions(-)


-- 
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1232739 — [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

From	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Date	2015-09-25 14:10 +0200
Subject	[V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly
Message-ID	<qczZ8-T1-9@gated-at.bofh.it>
In reply to	#1232738

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
    smp_send_stop() // stop other cpus
    infinite loop

If CPU 1 calls smp_send_stop() before nmi_shootdown_cpus(), kdump
fails.

In another case:

CPU 0:
  oops_end()
    crash_kexec()
      mutex_trylock() // acquired
        <NMI>
        io_check_error()
          panic()
            crash_kexec()
              mutex_trylock() // failed to acquire
            infinite loop

Clearly, this is an undesirable result.

To fix this problem, this patch changes crash_kexec() to exclude
others by using atomic_t panic_cpu.

V4:
- Use new __crash_kexec(), no exclusion check version of crash_kexec(),
  instead of checking if panic_cpu is the current cpu or not

V2:
- Use atomic_cmpxchg() instead of spin_trylock() on panic_lock
  to exclude concurrent accesses
- Don't introduce no-lock version of crash_kexec()

Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>
---
 include/linux/kexec.h |    1 +
 kernel/kexec_core.c   |   26 +++++++++++++++++++++++++-
 kernel/panic.c        |    4 ++--
 3 files changed, 28 insertions(+), 3 deletions(-)

diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index d140b1e..f0cd2fa 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -237,6 +237,7 @@ extern int kexec_purgatory_get_set_symbol(struct kimage *image,
 					  unsigned int size, bool get_value);
 extern void *kexec_purgatory_get_symbol_addr(struct kimage *image,
 					     const char *name);
+extern void __crash_kexec(struct pt_regs *);
 extern void crash_kexec(struct pt_regs *);
 int kexec_should_crash(struct task_struct *);
 void crash_save_cpu(struct pt_regs *regs, int cpu);
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 201b453..4edb20a 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -853,7 +853,8 @@ int kimage_load_segment(struct kimage *image,
 struct kimage *kexec_crash_image;
 int kexec_load_disabled;
 
-void crash_kexec(struct pt_regs *regs)
+/* No panic_cpu check version of crash_kexec */
+void __crash_kexec(struct pt_regs *regs)
 {
 	/* Take the kexec_mutex here to prevent sys_kexec_load
 	 * running on one cpu from replacing the crash kernel
@@ -876,6 +877,29 @@ void crash_kexec(struct pt_regs *regs)
 	}
 }
 
+void crash_kexec(struct pt_regs *regs)
+{
+	int old_cpu, this_cpu;
+
+	/*
+	 * Only one CPU is allowed to execute the crash_kexec() code as with
+	 * panic().  Otherwise parallel calls of panic() and crash_kexec()
+	 * may stop each other.  To exclude them, we use panic_cpu here too.
+	 */
+	this_cpu = raw_smp_processor_id();
+	old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu);
+	if (old_cpu == -1) {
+		/* This is the 1st CPU which comes here, so go ahead. */
+		__crash_kexec(regs);
+
+		/*
+		 * Reset panic_cpu to allow another panic()/crash_kexec()
+		 * call.
+		 */
+		atomic_xchg(&panic_cpu, -1);
+	}
+}
+
 size_t crash_get_memory_size(void)
 {
 	size_t size = 0;
diff --git a/kernel/panic.c b/kernel/panic.c
index cddbfe0..994be45 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -137,7 +137,7 @@ void panic(const char *fmt, ...)
 	 * the "crash_kexec_post_notifiers" option to the kernel.
 	 */
 	if (!crash_kexec_post_notifiers)
-		crash_kexec(NULL);
+		__crash_kexec(NULL);
 
 	/*
 	 * Note smp_send_stop is the usual smp shutdown function, which
@@ -162,7 +162,7 @@ void panic(const char *fmt, ...)
 	 * more unstable, it can increase risks of the kdump failure too.
 	 */
 	if (crash_kexec_post_notifiers)
-		crash_kexec(NULL);
+		__crash_kexec(NULL);
 
 	bust_spinlocks(0);
 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233837 — Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

From	kbuild test robot <lkp@intel.com>
Date	2015-09-28 06:10 +0200
Subject	Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly
Message-ID	<qdxVf-2W9-1@gated-at.bofh.it>
In reply to	#1232739

[Multipart message — attachments visible in raw view] — view raw

Hi Hidehiro,

[auto build test results on v4.3-rc2 -- if it's inappropriate base, please ignore]

config: x86_64-allnoconfig (attached as .config)
reproduce:
  git checkout 0077681103150af584e5e592c0238fd010654c26
  # save the attached .config to linux build tree
  make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   kernel/panic.c: In function 'panic':
>> kernel/panic.c:140:3: error: implicit declaration of function '__crash_kexec' [-Werror=implicit-function-declaration]
      __crash_kexec(NULL);
      ^
   cc1: some warnings being treated as errors

vim +/__crash_kexec +140 kernel/panic.c

   134		 * If we have crashed and we have a crash kernel loaded let it handle
   135		 * everything else.
   136		 * If we want to run this after calling panic_notifiers, pass
   137		 * the "crash_kexec_post_notifiers" option to the kernel.
   138		 */
   139		if (!crash_kexec_post_notifiers)
 > 140			__crash_kexec(NULL);
   141	
   142		/*
   143		 * Note smp_send_stop is the usual smp shutdown function, which

---
0-DAY kernel test infrastructure                Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all                   Intel Corporation

[toc] | [prev] | [next] | [standalone]

#1233840 — RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-09-28 06:50 +0200
Subject	RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly
Message-ID	<qdyxX-3GS-1@gated-at.bofh.it>
In reply to	#1233837

PiBIaSBIaWRlaGlybywNCj4gDQo+IFthdXRvIGJ1aWxkIHRlc3QgcmVzdWx0cyBvbiB2NC4zLXJj
MiAtLSBpZiBpdCdzIGluYXBwcm9wcmlhdGUgYmFzZSwgcGxlYXNlIGlnbm9yZV0NCj4gDQo+IGNv
bmZpZzogeDg2XzY0LWFsbG5vY29uZmlnIChhdHRhY2hlZCBhcyAuY29uZmlnKQ0KPiByZXByb2R1
Y2U6DQo+ICAgZ2l0IGNoZWNrb3V0IDAwNzc2ODExMDMxNTBhZjU4NGU1ZTU5MmMwMjM4ZmQwMTA2
NTRjMjYNCj4gICAjIHNhdmUgdGhlIGF0dGFjaGVkIC5jb25maWcgdG8gbGludXggYnVpbGQgdHJl
ZQ0KPiAgIG1ha2UgQVJDSD14ODZfNjQNCj4gDQo+IEFsbCBlcnJvci93YXJuaW5ncyAobmV3IG9u
ZXMgcHJlZml4ZWQgYnkgPj4pOg0KPiANCj4gICAga2VybmVsL3BhbmljLmM6IEluIGZ1bmN0aW9u
ICdwYW5pYyc6DQo+ID4+IGtlcm5lbC9wYW5pYy5jOjE0MDozOiBlcnJvcjogaW1wbGljaXQgZGVj
bGFyYXRpb24gb2YgZnVuY3Rpb24gJ19fY3Jhc2hfa2V4ZWMnIFstV2Vycm9yPWltcGxpY2l0LWZ1
bmN0aW9uLWRlY2xhcmF0aW9uXQ0KPiAgICAgICBfX2NyYXNoX2tleGVjKE5VTEwpOw0KPiAgICAg
ICBeDQoNClNvcnJ5LCBJIG1pc3NlZCB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgY2FzZSBvZiAh
Q09ORklHX0tFWEVDX0NPUkUuDQoNCiAjZWxzZSAvKiAhQ09ORklHX0tFWEVDX0NPUkUgKi8NCiBz
dHJ1Y3QgcHRfcmVnczsNCiBzdHJ1Y3QgdGFza19zdHJ1Y3Q7DQorc3RhdGljIGlubGluZSB2b2lk
IF9fY3Jhc2hfa2V4ZWMoc3RydWN0IHB0X3JlZ3MgKnJlZ3MpIHsgfQ0KIHN0YXRpYyBpbmxpbmUg
dm9pZCBjcmFzaF9rZXhlYyhzdHJ1Y3QgcHRfcmVncyAqcmVncykgeyB9DQogc3RhdGljIGlubGlu
ZSBpbnQga2V4ZWNfc2hvdWxkX2NyYXNoKHN0cnVjdCB0YXNrX3N0cnVjdCAqcCkgeyByZXR1cm4g
MDsgfQ0KDQpJJ2xsIHJlc2VuZCB0aGUgcmV2aXNlZCB2ZXJzaW9uIGxhdGVyLg0KDQo+ICAgIGNj
MTogc29tZSB3YXJuaW5ncyBiZWluZyB0cmVhdGVkIGFzIGVycm9ycw0KPiANCj4gdmltICsvX19j
cmFzaF9rZXhlYyArMTQwIGtlcm5lbC9wYW5pYy5jDQo+IA0KPiAgICAxMzQJCSAqIElmIHdlIGhh
dmUgY3Jhc2hlZCBhbmQgd2UgaGF2ZSBhIGNyYXNoIGtlcm5lbCBsb2FkZWQgbGV0IGl0IGhhbmRs
ZQ0KPiAgICAxMzUJCSAqIGV2ZXJ5dGhpbmcgZWxzZS4NCj4gICAgMTM2CQkgKiBJZiB3ZSB3YW50
IHRvIHJ1biB0aGlzIGFmdGVyIGNhbGxpbmcgcGFuaWNfbm90aWZpZXJzLCBwYXNzDQo+ICAgIDEz
NwkJICogdGhlICJjcmFzaF9rZXhlY19wb3N0X25vdGlmaWVycyIgb3B0aW9uIHRvIHRoZSBrZXJu
ZWwuDQo+ICAgIDEzOAkJICovDQo+ICAgIDEzOQkJaWYgKCFjcmFzaF9rZXhlY19wb3N0X25vdGlm
aWVycykNCj4gID4gMTQwCQkJX19jcmFzaF9rZXhlYyhOVUxMKTsNCj4gICAgMTQxDQo+ICAgIDE0
MgkJLyoNCj4gICAgMTQzCQkgKiBOb3RlIHNtcF9zZW5kX3N0b3AgaXMgdGhlIHVzdWFsIHNtcCBz
aHV0ZG93biBmdW5jdGlvbiwgd2hpY2gNCj4gDQo+IC0tLQ0KPiAwLURBWSBrZXJuZWwgdGVzdCBp
bmZyYXN0cnVjdHVyZSAgICAgICAgICAgICAgICBPcGVuIFNvdXJjZSBUZWNobm9sb2d5IENlbnRl
cg0KPiBodHRwczovL2xpc3RzLjAxLm9yZy9waXBlcm1haWwva2J1aWxkLWFsbCAgICAgICAgICAg
ICAgICAgICBJbnRlbCBDb3Jwb3JhdGlvbg0KDQoNCkhpZGVoaXJvIEthd2FpDQpIaXRhY2hpLCBM
dGQuIFJlc2VhcmNoICYgRGV2ZWxvcG1lbnQgR3JvdXANCg0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1233898 — RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-09-28 09:10 +0200
Subject	RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly
Message-ID	<qdAJs-6Z2-17@gated-at.bofh.it>
In reply to	#1232739

PiBIaSBIaWRlaGlybywNCj4gDQo+IFthdXRvIGJ1aWxkIHRlc3QgcmVzdWx0cyBvbiB2NC4zLXJj
MiAtLSBpZiBpdCdzIGluYXBwcm9wcmlhdGUgYmFzZSwgcGxlYXNlIGlnbm9yZV0NCj4gDQo+IGNv
bmZpZzogaWE2NC1hbGx5ZXNjb25maWcgKGF0dGFjaGVkIGFzIC5jb25maWcpDQo+IHJlcHJvZHVj
ZToNCj4gICB3Z2V0IGh0dHBzOi8vZ2l0Lmtlcm5lbC5vcmcvY2dpdC9saW51eC9rZXJuZWwvZ2l0
L3dmZy9sa3AtdGVzdHMuZ2l0L3BsYWluL3NiaW4vbWFrZS5jcm9zcyAtTyB+L2Jpbi9tYWtlLmNy
b3NzDQo+ICAgY2htb2QgK3ggfi9iaW4vbWFrZS5jcm9zcw0KPiAgIGdpdCBjaGVja291dCAwMDc3
NjgxMTAzMTUwYWY1ODRlNWU1OTJjMDIzOGZkMDEwNjU0YzI2DQo+ICAgIyBzYXZlIHRoZSBhdHRh
Y2hlZCAuY29uZmlnIHRvIGxpbnV4IGJ1aWxkIHRyZWUNCj4gICBtYWtlLmNyb3NzIEFSQ0g9aWE2
NA0KW3NuaXBdDQo+ICAgIGFyY2gvaWE2NC9pbmNsdWRlL3VhcGkvYXNtL2NtcHhjaGcuaDo1Njoy
OiB3YXJuaW5nOiB2YWx1ZSBjb21wdXRlZCBpcyBub3QgdXNlZCBbLVd1bnVzZWQtdmFsdWVdDQo+
ICAgICAoKF9fdHlwZW9mX18oKihwdHIpKSkgX194Y2hnKCh1bnNpZ25lZCBsb25nKSAoeCksIChw
dHIpLCBzaXplb2YoKihwdHIpKSkpDQo+ICAgICAgXg0KPiAgICBhcmNoL2lhNjQvaW5jbHVkZS9h
c20vYXRvbWljLmg6MTM1OjMwOiBub3RlOiBpbiBleHBhbnNpb24gb2YgbWFjcm8gJ3hjaGcnDQo+
ICAgICAjZGVmaW5lIGF0b21pY194Y2hnKHYsIG5ldykgKHhjaGcoJigodiktPmNvdW50ZXIpLCBu
ZXcpKQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBeDQo+ID4+IGtlcm5lbC9r
ZXhlY19jb3JlLmM6ODk5OjM6IG5vdGU6IGluIGV4cGFuc2lvbiBvZiBtYWNybyAnYXRvbWljX3hj
aGcnDQo+ICAgICAgIGF0b21pY194Y2hnKCZwYW5pY19jcHUsIC0xKTsNCj4gICAgICAgXg0KDQpJ
IGNoYW5nZWQgdG8gdXNlIGF0b21pY194Y2hnKCkgaW5zdGVhZCBvZiBhdG9taWNfc2V0KCkgaW4g
VjMNCmJlY2F1c2UgYXRvbWljX3NldCgpIGRvZXNuJ3QgbWVhbiBtZW1vcnkgYmFycmllci4gIEhv
d2V2ZXIsDQpJIHRob3VnaHQgYWdhaW4gYW5kIHRoZXJlIGlzIG5vIG5lZWQgb2YgYmFycmllcjsg
dGhlcmUgaXMgbm8NCnByb2JsZW0gaWYgYSBjb21wZXRpdG9yIHNlZXMgb2xkIHZhbHVlIG9mIHBh
bmljX2NwdSBvciBuZXcgb25lLg0KU28sIGF0b21pY19zZXQoKSBpcyBzdWZmaWNpZW50IGFuZCB1
c2luZyBpdCB3aWxsIHJlbW92ZSB0aGlzIHdhcm5pbmcuDQoNCkkgd2lsbCByZXNlbmQgdGhlIGZp
eGVkIHZlcnNpb24gbGF0ZXIuDQoNCj4gdmltICsvYXRvbWljX3hjaGcgKzg5OSBrZXJuZWwva2V4
ZWNfY29yZS5jDQo+IA0KPiAgICA4ODMNCj4gICAgODg0CQkvKg0KPiAgICA4ODUJCSAqIE9ubHkg
b25lIENQVSBpcyBhbGxvd2VkIHRvIGV4ZWN1dGUgdGhlIGNyYXNoX2tleGVjKCkgY29kZSBhcyB3
aXRoDQo+ICAgIDg4NgkJICogcGFuaWMoKS4gIE90aGVyd2lzZSBwYXJhbGxlbCBjYWxscyBvZiBw
YW5pYygpIGFuZCBjcmFzaF9rZXhlYygpDQo+ICAgIDg4NwkJICogbWF5IHN0b3AgZWFjaCBvdGhl
ci4gIFRvIGV4Y2x1ZGUgdGhlbSwgd2UgdXNlIHBhbmljX2NwdSBoZXJlIHRvby4NCj4gICAgODg4
CQkgKi8NCj4gICAgODg5CQl0aGlzX2NwdSA9IHJhd19zbXBfcHJvY2Vzc29yX2lkKCk7DQo+ICAg
IDg5MAkJb2xkX2NwdSA9IGF0b21pY19jbXB4Y2hnKCZwYW5pY19jcHUsIC0xLCB0aGlzX2NwdSk7
DQo+ICAgIDg5MQkJaWYgKG9sZF9jcHUgPT0gLTEpIHsNCj4gICAgODkyCQkJLyogVGhpcyBpcyB0
aGUgMXN0IENQVSB3aGljaCBjb21lcyBoZXJlLCBzbyBnbyBhaGVhZC4gKi8NCj4gICAgODkzCQkJ
X19jcmFzaF9rZXhlYyhyZWdzKTsNCj4gICAgODk0DQo+ICAgIDg5NQkJCS8qDQo+ICAgIDg5NgkJ
CSAqIFJlc2V0IHBhbmljX2NwdSB0byBhbGxvdyBhbm90aGVyIHBhbmljKCkvY3Jhc2hfa2V4ZWMo
KQ0KPiAgICA4OTcJCQkgKiBjYWxsLg0KPiAgICA4OTgJCQkgKi8NCj4gID4gODk5CQkJYXRvbWlj
X3hjaGcoJnBhbmljX2NwdSwgLTEpOw0KPiAgICA5MDAJCX0NCj4gICAgOTAxCX0NCj4gICAgOTAy
DQo+ICAgIDkwMwlzaXplX3QgY3Jhc2hfZ2V0X21lbW9yeV9zaXplKHZvaWQpDQo+ICAgIDkwNAl7
DQo+ICAgIDkwNQkJc2l6ZV90IHNpemUgPSAwOw0KPiAgICA5MDYNCj4gICAgOTA3CQltdXRleF9s
b2NrKCZrZXhlY19tdXRleCk7DQo+IA0KPiAtLS0NCj4gMC1EQVkga2VybmVsIHRlc3QgaW5mcmFz
dHJ1Y3R1cmUgICAgICAgICAgICAgICAgT3BlbiBTb3VyY2UgVGVjaG5vbG9neSBDZW50ZXINCj4g
aHR0cHM6Ly9saXN0cy4wMS5vcmcvcGlwZXJtYWlsL2tidWlsZC1hbGwgICAgICAgICAgICAgICAg
ICAgSW50ZWwgQ29ycG9yYXRpb24NCg0KDQpIaWRlaGlybyBLYXdhaQ0KSGl0YWNoaSwgTHRkLiBS
ZXNlYXJjaCAmIERldmVsb3BtZW50IEdyb3VwDQoNCg0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236211 — Re: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

From	Peter Zijlstra <peterz@infradead.org>
Date	2015-09-30 14:00 +0200
Subject	Re: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly
Message-ID	<qeodc-468-9@gated-at.bofh.it>
In reply to	#1233898

On Mon, Sep 28, 2015 at 07:08:19AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > >> kernel/kexec_core.c:899:3: note: in expansion of macro 'atomic_xchg'
> >       atomic_xchg(&panic_cpu, -1);
> >       ^
> 
> I changed to use atomic_xchg() instead of atomic_set() in V3
> because atomic_set() doesn't mean memory barrier.  However,
> I thought again and there is no need of barrier; there is no
> problem if a competitor sees old value of panic_cpu or new one.
> So, atomic_set() is sufficient and using it will remove this warning.
> 
> I will resend the fixed version later.

So if you rely on the memory barrier; you should have also put a comment
on explaining the ordering requirements.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236900 — RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-10-01 04:10 +0200
Subject	RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly
Message-ID	<qeBtL-6wQ-7@gated-at.bofh.it>
In reply to	#1236211

PiBPbiBNb24sIFNlcCAyOCwgMjAxNSBhdCAwNzowODoxOUFNICswMDAwLCDmsrPlkIjoi7Hlro8g
LyBLQVdBSe+8jEhJREVISVJPIHdyb3RlOg0KPiA+ID4gPj4ga2VybmVsL2tleGVjX2NvcmUuYzo4
OTk6Mzogbm90ZTogaW4gZXhwYW5zaW9uIG9mIG1hY3JvICdhdG9taWNfeGNoZycNCj4gPiA+ICAg
ICAgIGF0b21pY194Y2hnKCZwYW5pY19jcHUsIC0xKTsNCj4gPiA+ICAgICAgIF4NCj4gPg0KPiA+
IEkgY2hhbmdlZCB0byB1c2UgYXRvbWljX3hjaGcoKSBpbnN0ZWFkIG9mIGF0b21pY19zZXQoKSBp
biBWMw0KPiA+IGJlY2F1c2UgYXRvbWljX3NldCgpIGRvZXNuJ3QgbWVhbiBtZW1vcnkgYmFycmll
ci4gIEhvd2V2ZXIsDQo+ID4gSSB0aG91Z2h0IGFnYWluIGFuZCB0aGVyZSBpcyBubyBuZWVkIG9m
IGJhcnJpZXI7IHRoZXJlIGlzIG5vDQo+ID4gcHJvYmxlbSBpZiBhIGNvbXBldGl0b3Igc2VlcyBv
bGQgdmFsdWUgb2YgcGFuaWNfY3B1IG9yIG5ldyBvbmUuDQo+ID4gU28sIGF0b21pY19zZXQoKSBp
cyBzdWZmaWNpZW50IGFuZCB1c2luZyBpdCB3aWxsIHJlbW92ZSB0aGlzIHdhcm5pbmcuDQo+ID4N
Cj4gPiBJIHdpbGwgcmVzZW5kIHRoZSBmaXhlZCB2ZXJzaW9uIGxhdGVyLg0KPiANCj4gU28gaWYg
eW91IHJlbHkgb24gdGhlIG1lbW9yeSBiYXJyaWVyOyB5b3Ugc2hvdWxkIGhhdmUgYWxzbyBwdXQg
YSBjb21tZW50DQo+IG9uIGV4cGxhaW5pbmcgdGhlIG9yZGVyaW5nIHJlcXVpcmVtZW50cy4NCg0K
SSBkb24ndCBpbnRlbmQgdG8gdXNlIGFuIGV4cGxpY2l0IG1lbW9yeSBiYXJyaWVyLiAgVGhlcmUg
aXMgbm8NCm1lbW9yeSBvcmRlcmluZyByZXF1aXJlbWVudCBoZXJlLiAgQWxzbywgYXRvbWljX3Nl
dCgpIHdoaWNoIHdpbGwgYmUNCnVzZWQgaW5zdGVhZCBvZiBhdG9taWNfeGNoZygpIGlzIHVzZWQg
YXMgYSBSRUxFQVNFIG9wZXJhdGlvbiwgc28NCkkgYmVsaWV2ZSB0aGVyZSBpcyBubyBwcm9ibGVt
Lg0KDQpEb2N1bWVudGF0aW9uL21lbW9yeS1iYXJyaWVycy50eHQ6DQo+IFRoZSBmb2xsb3dpbmcg
b3BlcmF0aW9ucyBhcmUgcG90ZW50aWFsIHByb2JsZW1zIGFzIHRoZXkgZG8gX25vdF8gaW1wbHkg
bWVtb3J5DQo+IGJhcnJpZXJzLCBidXQgbWlnaHQgYmUgdXNlZCBmb3IgaW1wbGVtZW50aW5nIHN1
Y2ggdGhpbmdzIGFzIFJFTEVBU0UtY2xhc3MNCj4gb3BlcmF0aW9uczoNCj4gDQo+ICAgICAgICAg
YXRvbWljX3NldCgpOw0KPiAuLi4NCg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232741 — [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

From	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Date	2015-09-25 14:10 +0200
Subject	[V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI
Message-ID	<qczZ8-T1-17@gated-at.bofh.it>
In reply to	#1232738

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().

V4:
- Improve comments in io_check_error() and panic()

V3:
- Introduce nmi_panic() macro to reduce code duplication
- In the case of panic on NMI, don't return from NMI handlers
  if another cpu already panicked

V2:
- Use atomic_cmpxchg() instead of current spin_trylock() to
  exclude concurrent accesses to the panic routines
- Don't introduce no-lock version of panic()

Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Michal Hocko <mhocko@kernel.org>
---
 arch/x86/kernel/nmi.c  |   16 ++++++++++++----
 include/linux/kernel.h |   13 +++++++++++++
 kernel/panic.c         |   15 ++++++++++++---
 kernel/watchdog.c      |    2 +-
 4 files changed, 38 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 697f90d..5131714 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -231,7 +231,7 @@ void unregister_nmi_handler(unsigned int type, const char *name)
 #endif
 
 	if (panic_on_unrecovered_nmi)
-		panic("NMI: Not continuing");
+		nmi_panic("NMI: Not continuing");
 
 	pr_emerg("Dazed and confused, but trying to continue\n");
 
@@ -255,8 +255,16 @@ void unregister_nmi_handler(unsigned int type, const char *name)
 		 reason, smp_processor_id());
 	show_regs(regs);
 
-	if (panic_on_io_nmi)
-		panic("NMI IOCK error: Not continuing");
+	if (panic_on_io_nmi) {
+		nmi_panic("NMI IOCK error: Not continuing");
+
+		/*
+		 * If we return from nmi_panic(), it means we have received
+		 * NMI while processing panic().  So, simply return without
+		 * a delay and re-enabling NMI.
+		 */
+		return;
+	}
 
 	/* Re-enable the IOCK line, wait for a few seconds */
 	reason = (reason & NMI_REASON_CLEAR_MASK) | NMI_REASON_CLEAR_IOCHK;
@@ -297,7 +305,7 @@ void unregister_nmi_handler(unsigned int type, const char *name)
 
 	pr_emerg("Do you have a strange power saving mode enabled?\n");
 	if (unknown_nmi_panic || panic_on_unrecovered_nmi)
-		panic("NMI: Not continuing");
+		nmi_panic("NMI: Not continuing");
 
 	pr_emerg("Dazed and confused, but trying to continue\n");
 }
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5582410..57c33da 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -443,6 +443,19 @@ extern __scanf(2, 0)
 
 extern bool crash_kexec_post_notifiers;
 
+extern atomic_t panic_cpu;
+
+/*
+ * A variant of panic() called from NMI context.
+ * If we've already panicked on this cpu, return from here.
+ */
+#define nmi_panic(fmt, ...)						\
+	do {								\
+		int this_cpu = raw_smp_processor_id();			\
+		if (atomic_cmpxchg(&panic_cpu, -1, this_cpu) != this_cpu) \
+			panic(fmt, ##__VA_ARGS__);			\
+	} while (0)
+
 /*
  * Only to be used by arch init code. If the user over-wrote the default
  * CONFIG_PANIC_TIMEOUT, honor it.
diff --git a/kernel/panic.c b/kernel/panic.c
index 04e91ff..a105e67 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -60,6 +60,8 @@ void __weak panic_smp_self_stop(void)
 		cpu_relax();
 }
 
+atomic_t panic_cpu = ATOMIC_INIT(-1);
+
 /**
  *	panic - halt the system
  *	@fmt: The text string to print
@@ -70,17 +72,17 @@ void __weak panic_smp_self_stop(void)
  */
 void panic(const char *fmt, ...)
 {
-	static DEFINE_SPINLOCK(panic_lock);
 	static char buf[1024];
 	va_list args;
 	long i, i_next = 0;
 	int state = 0;
+	int old_cpu, this_cpu;
 
 	/*
 	 * Disable local interrupts. This will prevent panic_smp_self_stop
 	 * from deadlocking the first cpu that invokes the panic, since
 	 * there is nothing to prevent an interrupt handler (that runs
-	 * after the panic_lock is acquired) from invoking panic again.
+	 * after setting panic_cpu) from invoking panic again.
 	 */
 	local_irq_disable();
 
@@ -93,8 +95,15 @@ void panic(const char *fmt, ...)
 	 * multiple parallel invocations of panic, all other CPUs either
 	 * stop themself or will wait until they are stopped by the 1st CPU
 	 * with smp_send_stop().
+	 *
+	 * `old_cpu == -1' means this is the 1st CPU which comes here, so
+	 * go ahead.
+	 * `old_cpu == this_cpu' means we came from nmi_panic() which sets
+	 * panic_cpu to this cpu.  In this case, this is also the 1st CPU.
 	 */
-	if (!spin_trylock(&panic_lock))
+	this_cpu = raw_smp_processor_id();
+	old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu);
+	if (old_cpu != -1 && old_cpu != this_cpu)
 		panic_smp_self_stop();
 
 	console_verbose();
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 64ed1c3..00fbaa29 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -324,7 +324,7 @@ static void watchdog_overflow_callback(struct perf_event *event,
 			return;
 
 		if (hardlockup_panic)
-			panic("Watchdog detected hard LOCKUP on cpu %d",
+			nmi_panic("Watchdog detected hard LOCKUP on cpu %d",
 			      this_cpu);
 		else
 			WARN(1, "Watchdog detected hard LOCKUP on cpu %d",


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232755 — RE: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-09-25 14:20 +0200
Subject	RE: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI
Message-ID	<qcA8N-14l-1@gated-at.bofh.it>
In reply to	#1232741

UGV0ZXIgc2FpZHMgLXRpcCB0cmVlIGRvZXNuJ3QgaGF2ZSBwYW5pY19vbl91bnJlY292ZXJlZF9u
bWkgaW4gdGhlDQpwcmV2aW9pdXMgZGlzY3Vzc2lvbiwgYnV0IGl0IHN0aWxsIGV4aXN0cy4gIFNv
LCBJIGRpZG4ndCBjaGFuZ2UNCmFueXRoaW5nIGFib3V0IHBhbmljX29uX3VucmVjb3ZlcmVkX25t
aS4NCg0KVGhhbmtzLA0KDQpIaWRlaGlybyBLYXdhaQ0KSGl0YWNoaSwgTHRkLiBSZXNlYXJjaCAm
IERldmVsb3BtZW50IEdyb3VwDQoNCj4gRnJvbTogSGlkZWhpcm8gS2F3YWkgW21haWx0bzpoaWRl
aGlyby5rYXdhaS5lekBoaXRhY2hpLmNvbV0NCj4gDQo+IElmIHBhbmljIG9uIE5NSSBoYXBwZW5z
IGp1c3QgYWZ0ZXIgcGFuaWMoKSBvbiB0aGUgc2FtZSBDUFUsIHBhbmljKCkNCj4gaXMgcmVjdXJz
aXZlbHkgY2FsbGVkLiAgQXMgdGhlIHJlc3VsdCwgaXQgc3RhbGxzIGFmdGVyIGZhaWxpbmcgdG8N
Cj4gYWNxdWlyZSBwYW5pY19sb2NrLg0KPiANCj4gVG8gYXZvaWQgdGhpcyBwcm9ibGVtLCBkb24n
dCBjYWxsIHBhbmljKCkgaW4gTk1JIGNvbnRleHQgaWYNCj4gd2UndmUgYWxyZWFkeSBlbnRlcmVk
IHBhbmljKCkuDQo+IA0KPiBWNDoNCj4gLSBJbXByb3ZlIGNvbW1lbnRzIGluIGlvX2NoZWNrX2Vy
cm9yKCkgYW5kIHBhbmljKCkNCj4gDQo+IFYzOg0KPiAtIEludHJvZHVjZSBubWlfcGFuaWMoKSBt
YWNybyB0byByZWR1Y2UgY29kZSBkdXBsaWNhdGlvbg0KPiAtIEluIHRoZSBjYXNlIG9mIHBhbmlj
IG9uIE5NSSwgZG9uJ3QgcmV0dXJuIGZyb20gTk1JIGhhbmRsZXJzDQo+ICAgaWYgYW5vdGhlciBj
cHUgYWxyZWFkeSBwYW5pY2tlZA0KPiANCj4gVjI6DQo+IC0gVXNlIGF0b21pY19jbXB4Y2hnKCkg
aW5zdGVhZCBvZiBjdXJyZW50IHNwaW5fdHJ5bG9jaygpIHRvDQo+ICAgZXhjbHVkZSBjb25jdXJy
ZW50IGFjY2Vzc2VzIHRvIHRoZSBwYW5pYyByb3V0aW5lcw0KPiAtIERvbid0IGludHJvZHVjZSBu
by1sb2NrIHZlcnNpb24gb2YgcGFuaWMoKQ0KPiANCj4gU2lnbmVkLW9mZi1ieTogSGlkZWhpcm8g
S2F3YWkgPGhpZGVoaXJvLmthd2FpLmV6QGhpdGFjaGkuY29tPg0KPiBDYzogQW5kcmV3IE1vcnRv
biA8YWtwbUBsaW51eC1mb3VuZGF0aW9uLm9yZz4NCj4gQ2M6IFRob21hcyBHbGVpeG5lciA8dGds
eEBsaW51dHJvbml4LmRlPg0KPiBDYzogSW5nbyBNb2xuYXIgPG1pbmdvQHJlZGhhdC5jb20+DQo+
IENjOiAiSC4gUGV0ZXIgQW52aW4iIDxocGFAenl0b3IuY29tPg0KPiBDYzogUGV0ZXIgWmlqbHN0
cmEgPHBldGVyekBpbmZyYWRlYWQub3JnPg0KPiBDYzogTWljaGFsIEhvY2tvIDxtaG9ja29Aa2Vy
bmVsLm9yZz4NCj4gLS0tDQo+ICBhcmNoL3g4Ni9rZXJuZWwvbm1pLmMgIHwgICAxNiArKysrKysr
KysrKystLS0tDQo+ICBpbmNsdWRlL2xpbnV4L2tlcm5lbC5oIHwgICAxMyArKysrKysrKysrKysr
DQo+ICBrZXJuZWwvcGFuaWMuYyAgICAgICAgIHwgICAxNSArKysrKysrKysrKystLS0NCj4gIGtl
cm5lbC93YXRjaGRvZy5jICAgICAgfCAgICAyICstDQo+ICA0IGZpbGVzIGNoYW5nZWQsIDM4IGlu
c2VydGlvbnMoKyksIDggZGVsZXRpb25zKC0pDQo+IA0KPiBkaWZmIC0tZ2l0IGEvYXJjaC94ODYv
a2VybmVsL25taS5jIGIvYXJjaC94ODYva2VybmVsL25taS5jDQo+IGluZGV4IDY5N2Y5MGQuLjUx
MzE3MTQgMTAwNjQ0DQo+IC0tLSBhL2FyY2gveDg2L2tlcm5lbC9ubWkuYw0KPiArKysgYi9hcmNo
L3g4Ni9rZXJuZWwvbm1pLmMNCj4gQEAgLTIzMSw3ICsyMzEsNyBAQCB2b2lkIHVucmVnaXN0ZXJf
bm1pX2hhbmRsZXIodW5zaWduZWQgaW50IHR5cGUsIGNvbnN0IGNoYXIgKm5hbWUpDQo+ICAjZW5k
aWYNCj4gDQo+ICAJaWYgKHBhbmljX29uX3VucmVjb3ZlcmVkX25taSkNCj4gLQkJcGFuaWMoIk5N
STogTm90IGNvbnRpbnVpbmciKTsNCj4gKwkJbm1pX3BhbmljKCJOTUk6IE5vdCBjb250aW51aW5n
Iik7DQo+IA0KPiAgCXByX2VtZXJnKCJEYXplZCBhbmQgY29uZnVzZWQsIGJ1dCB0cnlpbmcgdG8g
Y29udGludWVcbiIpOw0KPiANCj4gQEAgLTI1NSw4ICsyNTUsMTYgQEAgdm9pZCB1bnJlZ2lzdGVy
X25taV9oYW5kbGVyKHVuc2lnbmVkIGludCB0eXBlLCBjb25zdCBjaGFyICpuYW1lKQ0KPiAgCQkg
cmVhc29uLCBzbXBfcHJvY2Vzc29yX2lkKCkpOw0KPiAgCXNob3dfcmVncyhyZWdzKTsNCj4gDQo+
IC0JaWYgKHBhbmljX29uX2lvX25taSkNCj4gLQkJcGFuaWMoIk5NSSBJT0NLIGVycm9yOiBOb3Qg
Y29udGludWluZyIpOw0KPiArCWlmIChwYW5pY19vbl9pb19ubWkpIHsNCj4gKwkJbm1pX3Bhbmlj
KCJOTUkgSU9DSyBlcnJvcjogTm90IGNvbnRpbnVpbmciKTsNCj4gKw0KPiArCQkvKg0KPiArCQkg
KiBJZiB3ZSByZXR1cm4gZnJvbSBubWlfcGFuaWMoKSwgaXQgbWVhbnMgd2UgaGF2ZSByZWNlaXZl
ZA0KPiArCQkgKiBOTUkgd2hpbGUgcHJvY2Vzc2luZyBwYW5pYygpLiAgU28sIHNpbXBseSByZXR1
cm4gd2l0aG91dA0KPiArCQkgKiBhIGRlbGF5IGFuZCByZS1lbmFibGluZyBOTUkuDQo+ICsJCSAq
Lw0KPiArCQlyZXR1cm47DQo+ICsJfQ0KPiANCj4gIAkvKiBSZS1lbmFibGUgdGhlIElPQ0sgbGlu
ZSwgd2FpdCBmb3IgYSBmZXcgc2Vjb25kcyAqLw0KPiAgCXJlYXNvbiA9IChyZWFzb24gJiBOTUlf
UkVBU09OX0NMRUFSX01BU0spIHwgTk1JX1JFQVNPTl9DTEVBUl9JT0NISzsNCj4gQEAgLTI5Nyw3
ICszMDUsNyBAQCB2b2lkIHVucmVnaXN0ZXJfbm1pX2hhbmRsZXIodW5zaWduZWQgaW50IHR5cGUs
IGNvbnN0IGNoYXIgKm5hbWUpDQo+IA0KPiAgCXByX2VtZXJnKCJEbyB5b3UgaGF2ZSBhIHN0cmFu
Z2UgcG93ZXIgc2F2aW5nIG1vZGUgZW5hYmxlZD9cbiIpOw0KPiAgCWlmICh1bmtub3duX25taV9w
YW5pYyB8fCBwYW5pY19vbl91bnJlY292ZXJlZF9ubWkpDQo+IC0JCXBhbmljKCJOTUk6IE5vdCBj
b250aW51aW5nIik7DQo+ICsJCW5taV9wYW5pYygiTk1JOiBOb3QgY29udGludWluZyIpOw0KPiAN
Cj4gIAlwcl9lbWVyZygiRGF6ZWQgYW5kIGNvbmZ1c2VkLCBidXQgdHJ5aW5nIHRvIGNvbnRpbnVl
XG4iKTsNCj4gIH0NCj4gZGlmZiAtLWdpdCBhL2luY2x1ZGUvbGludXgva2VybmVsLmggYi9pbmNs
dWRlL2xpbnV4L2tlcm5lbC5oDQo+IGluZGV4IDU1ODI0MTAuLjU3YzMzZGEgMTAwNjQ0DQo+IC0t
LSBhL2luY2x1ZGUvbGludXgva2VybmVsLmgNCj4gKysrIGIvaW5jbHVkZS9saW51eC9rZXJuZWwu
aA0KPiBAQCAtNDQzLDYgKzQ0MywxOSBAQCBleHRlcm4gX19zY2FuZigyLCAwKQ0KPiANCj4gIGV4
dGVybiBib29sIGNyYXNoX2tleGVjX3Bvc3Rfbm90aWZpZXJzOw0KPiANCj4gK2V4dGVybiBhdG9t
aWNfdCBwYW5pY19jcHU7DQo+ICsNCj4gKy8qDQo+ICsgKiBBIHZhcmlhbnQgb2YgcGFuaWMoKSBj
YWxsZWQgZnJvbSBOTUkgY29udGV4dC4NCj4gKyAqIElmIHdlJ3ZlIGFscmVhZHkgcGFuaWNrZWQg
b24gdGhpcyBjcHUsIHJldHVybiBmcm9tIGhlcmUuDQo+ICsgKi8NCj4gKyNkZWZpbmUgbm1pX3Bh
bmljKGZtdCwgLi4uKQkJCQkJCVwNCj4gKwlkbyB7CQkJCQkJCQlcDQo+ICsJCWludCB0aGlzX2Nw
dSA9IHJhd19zbXBfcHJvY2Vzc29yX2lkKCk7CQkJXA0KPiArCQlpZiAoYXRvbWljX2NtcHhjaGco
JnBhbmljX2NwdSwgLTEsIHRoaXNfY3B1KSAhPSB0aGlzX2NwdSkgXA0KPiArCQkJcGFuaWMoZm10
LCAjI19fVkFfQVJHU19fKTsJCQlcDQo+ICsJfSB3aGlsZSAoMCkNCj4gKw0KPiAgLyoNCj4gICAq
IE9ubHkgdG8gYmUgdXNlZCBieSBhcmNoIGluaXQgY29kZS4gSWYgdGhlIHVzZXIgb3Zlci13cm90
ZSB0aGUgZGVmYXVsdA0KPiAgICogQ09ORklHX1BBTklDX1RJTUVPVVQsIGhvbm9yIGl0Lg0KPiBk
aWZmIC0tZ2l0IGEva2VybmVsL3BhbmljLmMgYi9rZXJuZWwvcGFuaWMuYw0KPiBpbmRleCAwNGU5
MWZmLi5hMTA1ZTY3IDEwMDY0NA0KPiAtLS0gYS9rZXJuZWwvcGFuaWMuYw0KPiArKysgYi9rZXJu
ZWwvcGFuaWMuYw0KPiBAQCAtNjAsNiArNjAsOCBAQCB2b2lkIF9fd2VhayBwYW5pY19zbXBfc2Vs
Zl9zdG9wKHZvaWQpDQo+ICAJCWNwdV9yZWxheCgpOw0KPiAgfQ0KPiANCj4gK2F0b21pY190IHBh
bmljX2NwdSA9IEFUT01JQ19JTklUKC0xKTsNCj4gKw0KPiAgLyoqDQo+ICAgKglwYW5pYyAtIGhh
bHQgdGhlIHN5c3RlbQ0KPiAgICoJQGZtdDogVGhlIHRleHQgc3RyaW5nIHRvIHByaW50DQo+IEBA
IC03MCwxNyArNzIsMTcgQEAgdm9pZCBfX3dlYWsgcGFuaWNfc21wX3NlbGZfc3RvcCh2b2lkKQ0K
PiAgICovDQo+ICB2b2lkIHBhbmljKGNvbnN0IGNoYXIgKmZtdCwgLi4uKQ0KPiAgew0KPiAtCXN0
YXRpYyBERUZJTkVfU1BJTkxPQ0socGFuaWNfbG9jayk7DQo+ICAJc3RhdGljIGNoYXIgYnVmWzEw
MjRdOw0KPiAgCXZhX2xpc3QgYXJnczsNCj4gIAlsb25nIGksIGlfbmV4dCA9IDA7DQo+ICAJaW50
IHN0YXRlID0gMDsNCj4gKwlpbnQgb2xkX2NwdSwgdGhpc19jcHU7DQo+IA0KPiAgCS8qDQo+ICAJ
ICogRGlzYWJsZSBsb2NhbCBpbnRlcnJ1cHRzLiBUaGlzIHdpbGwgcHJldmVudCBwYW5pY19zbXBf
c2VsZl9zdG9wDQo+ICAJICogZnJvbSBkZWFkbG9ja2luZyB0aGUgZmlyc3QgY3B1IHRoYXQgaW52
b2tlcyB0aGUgcGFuaWMsIHNpbmNlDQo+ICAJICogdGhlcmUgaXMgbm90aGluZyB0byBwcmV2ZW50
IGFuIGludGVycnVwdCBoYW5kbGVyICh0aGF0IHJ1bnMNCj4gLQkgKiBhZnRlciB0aGUgcGFuaWNf
bG9jayBpcyBhY3F1aXJlZCkgZnJvbSBpbnZva2luZyBwYW5pYyBhZ2Fpbi4NCj4gKwkgKiBhZnRl
ciBzZXR0aW5nIHBhbmljX2NwdSkgZnJvbSBpbnZva2luZyBwYW5pYyBhZ2Fpbi4NCj4gIAkgKi8N
Cj4gIAlsb2NhbF9pcnFfZGlzYWJsZSgpOw0KPiANCj4gQEAgLTkzLDggKzk1LDE1IEBAIHZvaWQg
cGFuaWMoY29uc3QgY2hhciAqZm10LCAuLi4pDQo+ICAJICogbXVsdGlwbGUgcGFyYWxsZWwgaW52
b2NhdGlvbnMgb2YgcGFuaWMsIGFsbCBvdGhlciBDUFVzIGVpdGhlcg0KPiAgCSAqIHN0b3AgdGhl
bXNlbGYgb3Igd2lsbCB3YWl0IHVudGlsIHRoZXkgYXJlIHN0b3BwZWQgYnkgdGhlIDFzdCBDUFUN
Cj4gIAkgKiB3aXRoIHNtcF9zZW5kX3N0b3AoKS4NCj4gKwkgKg0KPiArCSAqIGBvbGRfY3B1ID09
IC0xJyBtZWFucyB0aGlzIGlzIHRoZSAxc3QgQ1BVIHdoaWNoIGNvbWVzIGhlcmUsIHNvDQo+ICsJ
ICogZ28gYWhlYWQuDQo+ICsJICogYG9sZF9jcHUgPT0gdGhpc19jcHUnIG1lYW5zIHdlIGNhbWUg
ZnJvbSBubWlfcGFuaWMoKSB3aGljaCBzZXRzDQo+ICsJICogcGFuaWNfY3B1IHRvIHRoaXMgY3B1
LiAgSW4gdGhpcyBjYXNlLCB0aGlzIGlzIGFsc28gdGhlIDFzdCBDUFUuDQo+ICAJICovDQo+IC0J
aWYgKCFzcGluX3RyeWxvY2soJnBhbmljX2xvY2spKQ0KPiArCXRoaXNfY3B1ID0gcmF3X3NtcF9w
cm9jZXNzb3JfaWQoKTsNCj4gKwlvbGRfY3B1ID0gYXRvbWljX2NtcHhjaGcoJnBhbmljX2NwdSwg
LTEsIHRoaXNfY3B1KTsNCj4gKwlpZiAob2xkX2NwdSAhPSAtMSAmJiBvbGRfY3B1ICE9IHRoaXNf
Y3B1KQ0KPiAgCQlwYW5pY19zbXBfc2VsZl9zdG9wKCk7DQo+IA0KPiAgCWNvbnNvbGVfdmVyYm9z
ZSgpOw0KPiBkaWZmIC0tZ2l0IGEva2VybmVsL3dhdGNoZG9nLmMgYi9rZXJuZWwvd2F0Y2hkb2cu
Yw0KPiBpbmRleCA2NGVkMWMzLi4wMGZiYWEyOSAxMDA2NDQNCj4gLS0tIGEva2VybmVsL3dhdGNo
ZG9nLmMNCj4gKysrIGIva2VybmVsL3dhdGNoZG9nLmMNCj4gQEAgLTMyNCw3ICszMjQsNyBAQCBz
dGF0aWMgdm9pZCB3YXRjaGRvZ19vdmVyZmxvd19jYWxsYmFjayhzdHJ1Y3QgcGVyZl9ldmVudCAq
ZXZlbnQsDQo+ICAJCQlyZXR1cm47DQo+IA0KPiAgCQlpZiAoaGFyZGxvY2t1cF9wYW5pYykNCj4g
LQkJCXBhbmljKCJXYXRjaGRvZyBkZXRlY3RlZCBoYXJkIExPQ0tVUCBvbiBjcHUgJWQiLA0KPiAr
CQkJbm1pX3BhbmljKCJXYXRjaGRvZyBkZXRlY3RlZCBoYXJkIExPQ0tVUCBvbiBjcHUgJWQiLA0K
PiAgCQkJICAgICAgdGhpc19jcHUpOw0KPiAgCQllbHNlDQo+ICAJCQlXQVJOKDEsICJXYXRjaGRv
ZyBkZXRlY3RlZCBoYXJkIExPQ0tVUCBvbiBjcHUgJWQiLA0KPiANCg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236177 — Re: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

From	Peter Zijlstra <peterz@infradead.org>
Date	2015-09-30 13:30 +0200
Subject	Re: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI
Message-ID	<qenKa-3xS-5@gated-at.bofh.it>
In reply to	#1232755

On Fri, Sep 25, 2015 at 12:13:55PM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> Peter saids -tip tree doesn't have panic_on_unrecovered_nmi in the
> previoius discussion, but it still exists.  So, I didn't change
> anything about panic_on_unrecovered_nmi.
> 

> > --- a/arch/x86/kernel/nmi.c
> > +++ b/arch/x86/kernel/nmi.c
> > @@ -231,7 +231,7 @@ void unregister_nmi_handler(unsigned int type, const char *name)
> >  #endif
> > 
> >  	if (panic_on_unrecovered_nmi)
> > -		panic("NMI: Not continuing");
> > +		nmi_panic("NMI: Not continuing");
> > 
> >  	pr_emerg("Dazed and confused, but trying to continue\n");
> > 

I was looking at unregister_nmi_handler() because that's the function
the diff points to. That still doesn't have panic_on_unrecovered_nmi.

It looks like your diff tool is 'broken' and generates nonsense function
data.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236889 — RE: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-10-01 03:10 +0200
Subject	RE: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI
Message-ID	<qeAxI-5di-1@gated-at.bofh.it>
In reply to	#1236177

PiBPbiBGcmksIFNlcCAyNSwgMjAxNSBhdCAxMjoxMzo1NVBNICswMDAwLCDmsrPlkIjoi7Hlro8g
LyBLQVdBSe+8jEhJREVISVJPIHdyb3RlOg0KPiA+IFBldGVyIHNhaWRzIC10aXAgdHJlZSBkb2Vz
bid0IGhhdmUgcGFuaWNfb25fdW5yZWNvdmVyZWRfbm1pIGluIHRoZQ0KPiA+IHByZXZpb2l1cyBk
aXNjdXNzaW9uLCBidXQgaXQgc3RpbGwgZXhpc3RzLiAgU28sIEkgZGlkbid0IGNoYW5nZQ0KPiA+
IGFueXRoaW5nIGFib3V0IHBhbmljX29uX3VucmVjb3ZlcmVkX25taS4NCj4gPg0KPiANCj4gPiA+
IC0tLSBhL2FyY2gveDg2L2tlcm5lbC9ubWkuYw0KPiA+ID4gKysrIGIvYXJjaC94ODYva2VybmVs
L25taS5jDQo+ID4gPiBAQCAtMjMxLDcgKzIzMSw3IEBAIHZvaWQgdW5yZWdpc3Rlcl9ubWlfaGFu
ZGxlcih1bnNpZ25lZCBpbnQgdHlwZSwgY29uc3QgY2hhciAqbmFtZSkNCj4gPiA+ICAjZW5kaWYN
Cj4gPiA+DQo+ID4gPiAgCWlmIChwYW5pY19vbl91bnJlY292ZXJlZF9ubWkpDQo+ID4gPiAtCQlw
YW5pYygiTk1JOiBOb3QgY29udGludWluZyIpOw0KPiA+ID4gKwkJbm1pX3BhbmljKCJOTUk6IE5v
dCBjb250aW51aW5nIik7DQo+ID4gPg0KPiA+ID4gIAlwcl9lbWVyZygiRGF6ZWQgYW5kIGNvbmZ1
c2VkLCBidXQgdHJ5aW5nIHRvIGNvbnRpbnVlXG4iKTsNCj4gPiA+DQo+IA0KPiBJIHdhcyBsb29r
aW5nIGF0IHVucmVnaXN0ZXJfbm1pX2hhbmRsZXIoKSBiZWNhdXNlIHRoYXQncyB0aGUgZnVuY3Rp
b24NCj4gdGhlIGRpZmYgcG9pbnRzIHRvLiBUaGF0IHN0aWxsIGRvZXNuJ3QgaGF2ZSBwYW5pY19v
bl91bnJlY292ZXJlZF9ubWkuDQo+IA0KPiBJdCBsb29rcyBsaWtlIHlvdXIgZGlmZiB0b29sIGlz
ICdicm9rZW4nIGFuZCBnZW5lcmF0ZXMgbm9uc2Vuc2UgZnVuY3Rpb24NCj4gZGF0YS4NCg0KSSBo
YWQgbm90aWNlZCB0aGUgZnVuY3Rpb24gbmFtZSBpcyB3cm9uZywgYnV0IEkgZGlkbid0IGtub3cg
aG93DQpkbyBJIGZpeCB0aGF0LCBzb3JyeS4gIE5vdywgSSB1cGRhdGVkIGdpdCB0byB0aGUgbGF0
ZXN0IHZlcnNpb24NCmFuZCB0aGUgaXNzdWUgZGlzYXBwZWFyZWQuDQoNClJlZ2FyZHMsDQoNCkhp
ZGVoaXJvIEthd2FpDQpIaXRhY2hpLCBMdGQuIFJlc2VhcmNoICYgRGV2ZWxvcG1lbnQgR3JvdXAN
Cg0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1232743 — [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Date	2015-09-25 14:10 +0200
Subject	[V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qczZ8-T1-23@gated-at.bofh.it>
In reply to	#1232738

This patch introduces new boot option "noextnmi" which disables
external NMI.  This option is useful for the dump capture kernel
so that an HA application or administrator wouldn't mistakenly
shoot down the kernel by NMI.

Currently, only x86 supports this option.

Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Jonathan Corbet <corbet@lwn.net>
---
 Documentation/kernel-parameters.txt |    4 ++++
 arch/x86/kernel/apic/apic.c         |   17 ++++++++++++++++-
 2 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 22a4b68..8bcaccd 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2379,6 +2379,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 			noexec=on: enable non-executable mappings (default)
 			noexec=off: disable non-executable mappings
 
+	noextnmi	[X86]
+			Mask external NMI.  This option is useful for a
+			dump capture kernel to be shot down by NMI.
+
 	nosmap		[X86]
 			Disable SMAP (Supervisor Mode Access Prevention)
 			even if it is supported by processor.
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index 24e94ce..fd47128 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -82,6 +82,12 @@
 static unsigned int disabled_cpu_apicid __read_mostly = BAD_APICID;
 
 /*
+ * Don't enable external NMI via LINT1 on BSP.  This is useful for
+ * the dump capture kernel.
+ */
+static bool apic_noextnmi;
+
+/*
  * Map cpu index to physical APIC ID
  */
 DEFINE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid, BAD_APICID);
@@ -1161,6 +1167,8 @@ void __init init_bsp_APIC(void)
 	value = APIC_DM_NMI;
 	if (!lapic_is_integrated())		/* 82489DX */
 		value |= APIC_LVT_LEVEL_TRIGGER;
+	if (apic_noextnmi)
+		value |= APIC_LVT_MASKED;
 	apic_write(APIC_LVT1, value);
 }
 
@@ -1380,7 +1388,7 @@ void setup_local_APIC(void)
 	/*
 	 * only the BP should see the LINT1 NMI signal, obviously.
 	 */
-	if (!cpu)
+	if (!cpu && !apic_noextnmi)
 		value = APIC_DM_NMI;
 	else
 		value = APIC_DM_NMI | APIC_LVT_MASKED;
@@ -2548,3 +2556,10 @@ static int __init apic_set_disabled_cpu_apicid(char *arg)
 	return 0;
 }
 early_param("disable_cpu_apicid", apic_set_disabled_cpu_apicid);
+
+static int __init apic_set_noextnmi(char *arg)
+{
+	apic_noextnmi = true;
+	return 0;
+}
+early_param("noextnmi", apic_set_noextnmi);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236213 — Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	Peter Zijlstra <peterz@infradead.org>
Date	2015-09-30 14:00 +0200
Subject	Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qeodd-468-19@gated-at.bofh.it>
In reply to	#1232743

On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote:
> This patch introduces new boot option "noextnmi" which disables
> external NMI.  This option is useful for the dump capture kernel
> so that an HA application or administrator wouldn't mistakenly
> shoot down the kernel by NMI.

So that they can get really stuck when the crash kernel crashes, right?
;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236910 — RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-10-01 04:40 +0200
Subject	RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qeBWN-7aJ-3@gated-at.bofh.it>
In reply to	#1236213

PiBPbiBGcmksIFNlcCAyNSwgMjAxNSBhdCAwODoyODoxMVBNICswOTAwLCBIaWRlaGlybyBLYXdh
aSB3cm90ZToNCj4gPiBUaGlzIHBhdGNoIGludHJvZHVjZXMgbmV3IGJvb3Qgb3B0aW9uICJub2V4
dG5taSIgd2hpY2ggZGlzYWJsZXMNCj4gPiBleHRlcm5hbCBOTUkuICBUaGlzIG9wdGlvbiBpcyB1
c2VmdWwgZm9yIHRoZSBkdW1wIGNhcHR1cmUga2VybmVsDQo+ID4gc28gdGhhdCBhbiBIQSBhcHBs
aWNhdGlvbiBvciBhZG1pbmlzdHJhdG9yIHdvdWxkbid0IG1pc3Rha2VubHkNCj4gPiBzaG9vdCBk
b3duIHRoZSBrZXJuZWwgYnkgTk1JLg0KPiANCj4gU28gdGhhdCB0aGV5IGNhbiBnZXQgcmVhbGx5
IHN0dWNrIHdoZW4gdGhlIGNyYXNoIGtlcm5lbCBjcmFzaGVzLCByaWdodD8NCj4gOy0pDQoNCk5v
LCBpdCBpcyBkaWZmZXJlbnQgZnJvbSBteSBpbnRlbnRpb24uDQoNCmBtaXN0YWtlbmx5JyBpbiB0
aGUgYWJvdmUgbWVhbnM7IHRoZXkgaXNzdWUgTk1JIGR1ZSB0byBhIG1pc2NvbmNlcHRpb24NCnRo
YXQgdGhlIG1vbml0b3JlZCBob3N0IGlzIHN0dWNrIGluIHRoZSAxc3Qga2VybmVsIHdoaWxlIGl0
IGlzIGFjdHVhbGx5DQp0YWtpbmcgYSBjcmFzaCBkdW1wIGluIHRoZSAybmQga2VybmVsLiAgVG8g
YXZvaWQgdGhpcyBraW5kIG9mIGFjY2lkZW50LA0KdGhlcmUgaXMgYSB0b29sIHN1Y2ggYXMgZmVu
Y2Vfa2R1bXAgd2hpY2ggbm90aWZpZXMgIkknbSB0YWtpbmcgYSBjcmFzaA0KZHVtcCwgc28gZG9u
J3Qgc2VuZCBOTUkiIHRvIHRoZSBIQSBjbHVzdGVyaW5nIHNvZnR3YXJlLiAgSG93ZXZlciwgdGhl
cmUNCmlzIGEgdGltZSB3aW5kb3cgYmV0d2VlbiBrZXJuZWwgcGFuaWMgYW5kIHRoZSBub3RpZmlj
YXRpb24uDQoNCiJub2V4dG5taSIgYWxsb3dzIHVzZXJzIHRvIGF2b2lkIHRoaXMga2luZCBvZiBh
Y2NpZGVudCBhbGwgdGhlIHRpbWUgb2YNCjJuZCBrZXJuZWwuDQoNClJlZ2FyZHMsDQoNCg0KSGlk
ZWhpcm8gS2F3YWkNCkhpdGFjaGksIEx0ZC4gUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBHcm91cA0K
DQoNCg0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237028 — Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	Peter Zijlstra <peterz@infradead.org>
Date	2015-10-01 08:30 +0200
Subject	Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qeFxn-3Zt-3@gated-at.bofh.it>
In reply to	#1236910

On Thu, Oct 01, 2015 at 02:33:18AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > On Fri, Sep 25, 2015 at 08:28:11PM +0900, Hidehiro Kawai wrote:
> > > This patch introduces new boot option "noextnmi" which disables
> > > external NMI.  This option is useful for the dump capture kernel
> > > so that an HA application or administrator wouldn't mistakenly
> > > shoot down the kernel by NMI.
> > 
> > So that they can get really stuck when the crash kernel crashes, right?
> > ;-)
> 
> No, it is different from my intention.
> 
> `mistakenly' in the above means; they issue NMI due to a misconception
> that the monitored host is stuck in the 1st kernel while it is actually
> taking a crash dump in the 2nd kernel.  To avoid this kind of accident,
> there is a tool such as fence_kdump which notifies "I'm taking a crash
> dump, so don't send NMI" to the HA clustering software.  However, there
> is a time window between kernel panic and the notification.
> 
> "noextnmi" allows users to avoid this kind of accident all the time of
> 2nd kernel.

Yes yes, I understand. But if the crash kernel also gets stuck they have
no means of recovery, right? (other than power cycling the hardware)

Just playing devils advocate here, I don't actually object to the patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237054 — RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-10-01 09:10 +0200
Subject	RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qeGa5-4Xv-3@gated-at.bofh.it>
In reply to	#1237028

PiBPbiBUaHUsIE9jdCAwMSwgMjAxNSBhdCAwMjozMzoxOEFNICswMDAwLCDmsrPlkIjoi7Hlro8g
LyBLQVdBSe+8jEhJREVISVJPIHdyb3RlOg0KPiA+ID4gT24gRnJpLCBTZXAgMjUsIDIwMTUgYXQg
MDg6Mjg6MTFQTSArMDkwMCwgSGlkZWhpcm8gS2F3YWkgd3JvdGU6DQo+ID4gPiA+IFRoaXMgcGF0
Y2ggaW50cm9kdWNlcyBuZXcgYm9vdCBvcHRpb24gIm5vZXh0bm1pIiB3aGljaCBkaXNhYmxlcw0K
PiA+ID4gPiBleHRlcm5hbCBOTUkuICBUaGlzIG9wdGlvbiBpcyB1c2VmdWwgZm9yIHRoZSBkdW1w
IGNhcHR1cmUga2VybmVsDQo+ID4gPiA+IHNvIHRoYXQgYW4gSEEgYXBwbGljYXRpb24gb3IgYWRt
aW5pc3RyYXRvciB3b3VsZG4ndCBtaXN0YWtlbmx5DQo+ID4gPiA+IHNob290IGRvd24gdGhlIGtl
cm5lbCBieSBOTUkuDQo+ID4gPg0KPiA+ID4gU28gdGhhdCB0aGV5IGNhbiBnZXQgcmVhbGx5IHN0
dWNrIHdoZW4gdGhlIGNyYXNoIGtlcm5lbCBjcmFzaGVzLCByaWdodD8NCj4gPiA+IDstKQ0KPiA+
DQo+ID4gTm8sIGl0IGlzIGRpZmZlcmVudCBmcm9tIG15IGludGVudGlvbi4NCj4gPg0KPiA+IGBt
aXN0YWtlbmx5JyBpbiB0aGUgYWJvdmUgbWVhbnM7IHRoZXkgaXNzdWUgTk1JIGR1ZSB0byBhIG1p
c2NvbmNlcHRpb24NCj4gPiB0aGF0IHRoZSBtb25pdG9yZWQgaG9zdCBpcyBzdHVjayBpbiB0aGUg
MXN0IGtlcm5lbCB3aGlsZSBpdCBpcyBhY3R1YWxseQ0KPiA+IHRha2luZyBhIGNyYXNoIGR1bXAg
aW4gdGhlIDJuZCBrZXJuZWwuICBUbyBhdm9pZCB0aGlzIGtpbmQgb2YgYWNjaWRlbnQsDQo+ID4g
dGhlcmUgaXMgYSB0b29sIHN1Y2ggYXMgZmVuY2Vfa2R1bXAgd2hpY2ggbm90aWZpZXMgIkknbSB0
YWtpbmcgYSBjcmFzaA0KPiA+IGR1bXAsIHNvIGRvbid0IHNlbmQgTk1JIiB0byB0aGUgSEEgY2x1
c3RlcmluZyBzb2Z0d2FyZS4gIEhvd2V2ZXIsIHRoZXJlDQo+ID4gaXMgYSB0aW1lIHdpbmRvdyBi
ZXR3ZWVuIGtlcm5lbCBwYW5pYyBhbmQgdGhlIG5vdGlmaWNhdGlvbi4NCj4gPg0KPiA+ICJub2V4
dG5taSIgYWxsb3dzIHVzZXJzIHRvIGF2b2lkIHRoaXMga2luZCBvZiBhY2NpZGVudCBhbGwgdGhl
IHRpbWUgb2YNCj4gPiAybmQga2VybmVsLg0KPiANCj4gWWVzIHllcywgSSB1bmRlcnN0YW5kLiBC
dXQgaWYgdGhlIGNyYXNoIGtlcm5lbCBhbHNvIGdldHMgc3R1Y2sgdGhleSBoYXZlDQo+IG5vIG1l
YW5zIG9mIHJlY292ZXJ5LCByaWdodD8gKG90aGVyIHRoYW4gcG93ZXIgY3ljbGluZyB0aGUgaGFy
ZHdhcmUpDQoNClllcywgYnV0IEkgdGhpbmsgaXQncyBub3QgYSBiaWcgcHJvYmxlbS4NCg0KSSBz
dXBwb3NlIHRoYXQgYSBzZXZlciB3aGljaCB1c2VzIHRoaXMgZmVhdHVyZSB3aWxsIGVxdWlwIGEg
Qk1DDQphbmQgQk1DIG1hbmRhdG9yaWx5IHN1cHBvcnRzIGhhcmQgcmVzZXQgY29tbWFuZCBmb3Ig
dGhlIHNlcnZlci4NCklmIHRoZSBIQSBjbHVzdGVyaW5nIHNvZnR3YXJlIGRldGVjdHMgbm8gcmVz
cG9uc2UgZnJvbSB0aGUgc2VydmVyDQphZnRlciByZWxhdGl2ZWx5IGxvbmcgdGltZW91dCwgaXQg
bWlnaHQgd2FudCB0byBpbnNlcnQgaGFyZCByZXNldA0KdG8gdGhlIHNlcnZlciBieSBJUE1JIG92
ZXIgTEFOLg0KDQo+IEp1c3QgcGxheWluZyBkZXZpbHMgYWR2b2NhdGUgaGVyZSwgSSBkb24ndCBh
Y3R1YWxseSBvYmplY3QgdG8gdGhlIHBhdGNoLg0KDQpSZWdhcmRzLA0KDQpIaWRlaGlybyBLYXdh
aQ0KSGl0YWNoaSwgTHRkLiBSZXNlYXJjaCAmIERldmVsb3BtZW50IEdyb3VwDQoNCg0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237151 — Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	Borislav Petkov <bp@alien8.de>
Date	2015-10-01 10:50 +0200
Subject	Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qeHIS-7lL-23@gated-at.bofh.it>
In reply to	#1237054

On Thu, Oct 01, 2015 at 07:01:50AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> I suppose that a sever which uses this feature will equip a BMC
> and BMC mandatorily supports hard reset command for the server.
> If the HA clustering software detects no response from the server
> after relatively long timeout, it might want to insert hard reset
> to the server by IPMI over LAN.

So why doesn't the capture kernel *automatically* ignore external NMIs,
without a cmdline option?

Before it starts capturing, it says: "I'm starting capturing and am
ignoring external NMIs from now on."

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237253 — RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-10-01 12:30 +0200
Subject	RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qeJhD-1fx-1@gated-at.bofh.it>
In reply to	#1237151

PiBPbiBUaHUsIE9jdCAwMSwgMjAxNSBhdCAwNzowMTo1MEFNICswMDAwLCDmsrPlkIjoi7Hlro8g
LyBLQVdBSe+8jEhJREVISVJPIHdyb3RlOg0KPiA+IEkgc3VwcG9zZSB0aGF0IGEgc2V2ZXIgd2hp
Y2ggdXNlcyB0aGlzIGZlYXR1cmUgd2lsbCBlcXVpcCBhIEJNQw0KPiA+IGFuZCBCTUMgbWFuZGF0
b3JpbHkgc3VwcG9ydHMgaGFyZCByZXNldCBjb21tYW5kIGZvciB0aGUgc2VydmVyLg0KPiA+IElm
IHRoZSBIQSBjbHVzdGVyaW5nIHNvZnR3YXJlIGRldGVjdHMgbm8gcmVzcG9uc2UgZnJvbSB0aGUg
c2VydmVyDQo+ID4gYWZ0ZXIgcmVsYXRpdmVseSBsb25nIHRpbWVvdXQsIGl0IG1pZ2h0IHdhbnQg
dG8gaW5zZXJ0IGhhcmQgcmVzZXQNCj4gPiB0byB0aGUgc2VydmVyIGJ5IElQTUkgb3ZlciBMQU4u
DQo+IA0KPiBTbyB3aHkgZG9lc24ndCB0aGUgY2FwdHVyZSBrZXJuZWwgKmF1dG9tYXRpY2FsbHkq
IGlnbm9yZSBleHRlcm5hbCBOTUlzLA0KPiB3aXRob3V0IGEgY21kbGluZSBvcHRpb24/DQo+IA0K
PiBCZWZvcmUgaXQgc3RhcnRzIGNhcHR1cmluZywgaXQgc2F5czogIkknbSBzdGFydGluZyBjYXB0
dXJpbmcgYW5kIGFtDQo+IGlnbm9yaW5nIGV4dGVybmFsIE5NSXMgZnJvbSBub3cgb24uIg0KDQpC
dXQgaG93IGRvIHdlIGNoZWNrIGlmIHRoZSBzdGFydGluZyBrZXJuZWwgaXMgYSBkdW1wIGNhcHR1
cmUga2VybmVsPw0KSSB0aGluayB1c2luZyBjbWRsaW5lIG9wdGlvbiBpcyB0aGUgc2ltcGxlc3Qg
d2F5LiAgWW91IGp1c3QgaGF2ZSB0bw0KYWRkICJub2V4dG5taSIgdG8gS0RVTVBfQ09NTUFORExJ
TkVfQVBQRU5EIGluIC9ldGMvc3lzY29uZmlnL2tkdW1wLg0KDQpSZWdhcmRzLA0KDQpIaWRlaGly
byBLYXdhaQ0KSGl0YWNoaSwgTHRkLiBSZXNlYXJjaCAmIERldmVsb3BtZW50IEdyb3VwDQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237275 — Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	Borislav Petkov <bp@alien8.de>
Date	2015-10-01 13:10 +0200
Subject	Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qeJUm-2dw-19@gated-at.bofh.it>
In reply to	#1237253

On Thu, Oct 01, 2015 at 10:24:19AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> But how do we check if the starting kernel is a dump capture kernel?

How does that first kernel pass info to the capture kernel?

> I think using cmdline option is the simplest way.

More often than not, simplest != correct.

What happens if I pass this option to the first kernel? All of a sudden
my *first* kernel doesn't get external NMIs.

Do you catch my drift?

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1237859 — RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

From	河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com>
Date	2015-10-02 03:00 +0200
Subject	RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
Message-ID	<qeWRA-4rJ-15@gated-at.bofh.it>
In reply to	#1237275

PiBPbiBUaHUsIE9jdCAwMSwgMjAxNSBhdCAxMDoyNDoxOUFNICswMDAwLCDmsrPlkIjoi7Hlro8g
LyBLQVdBSe+8jEhJREVISVJPIHdyb3RlOg0KPiA+IEJ1dCBob3cgZG8gd2UgY2hlY2sgaWYgdGhl
IHN0YXJ0aW5nIGtlcm5lbCBpcyBhIGR1bXAgY2FwdHVyZSBrZXJuZWw/DQo+IA0KPiBIb3cgZG9l
cyB0aGF0IGZpcnN0IGtlcm5lbCBwYXNzIGluZm8gdG8gdGhlIGNhcHR1cmUga2VybmVsPw0KDQpB
cyBJIGRlc2NyaWJlZCBpbiB0aGUgcHJldmlvdXMgbWFpbCwgWW91IGp1c3QgaGF2ZSB0byBhZGQg
Im5vZXh0bm1pIg0KdG8gS0RVTVBfQ09NTUFORExJTkVfQVBQRU5EIGluIC9ldGMvc3lzY29uZmln
L2tkdW1wLiAgVGhlbiwgIm5vZXh0bm1pIg0Kb3B0aW9uIGlzIHBhc3NlZCB0byB0aGUgY2FwdHVy
ZSBrZXJuZWwgYnkgdGhlIGFjdGlvbiBvZiBrZXhlYyBjb21tYW5kLg0KDQpDbWRsaW5lIG9wdGlv
biBnaXZlcyB1c2VycyBmbGV4aWJpbGl0eS4gIEknbSBub3Qgc3VyZSBhbGwgdXNlcnMNCndhbnQg
dG8gZGlzYWJsZSBleHRlcm5hbCBOTUlzIGluIHRoZSAybmQga2VybmVsLg0KDQo+ID4gSSB0aGlu
ayB1c2luZyBjbWRsaW5lIG9wdGlvbiBpcyB0aGUgc2ltcGxlc3Qgd2F5Lg0KPiANCj4gTW9yZSBv
ZnRlbiB0aGFuIG5vdCwgc2ltcGxlc3QgIT0gY29ycmVjdC4NCj4gDQo+IFdoYXQgaGFwcGVucyBp
ZiBJIHBhc3MgdGhpcyBvcHRpb24gdG8gdGhlIGZpcnN0IGtlcm5lbD8gQWxsIG9mIGEgc3VkZGVu
DQo+IG15ICpmaXJzdCoga2VybmVsIGRvZXNuJ3QgZ2V0IGV4dGVybmFsIE5NSXMuDQoNClllcywg
eW91ciBmaXJzdCBrZXJuZWwgZG9lc24ndCBnZXQgZXh0ZXJuYWwgTk1JcywgYnV0IGJhc2ljYWxs
eQ0KeW91IGRvbid0IGhhdmUgdG8gc2V0ICJub2V4dG5taSIgb3B0aW9uIHRvIHRoZSBmaXJzdCBr
ZXJuZWwuDQoNCg0KSGlkZWhpcm8gS2F3YWkNCkhpdGFjaGksIEx0ZC4gUmVzZWFyY2ggJiBEZXZl
bG9wbWVudCBHcm91cA0KDQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

Page 1 of 2 [1] 2 Next page →

csiph-web

[V4 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec

Contents

#1232738 — [V4 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec

#1232739 — [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

#1233837 — Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

#1233840 — RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

#1233898 — RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

#1236211 — Re: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

#1236900 — RE: Re: [V4 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly

#1232741 — [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

#1232755 — RE: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

#1236177 — Re: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

#1236889 — RE: [V4 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI

#1232743 — [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

#1236213 — Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

#1236910 — RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

#1237028 — Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

#1237054 — RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

#1237151 — Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

#1237253 — RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

#1237275 — Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

#1237859 — RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option