Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1232738 > unrolled thread
| 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 | 8 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 2 of 2 — ← Prev page 1 [2]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2015-10-02 09:50 +0200 |
| Subject | Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option |
| Message-ID | <qf3gl-5mM-1@gated-at.bofh.it> |
| In reply to | #1237859 |
On Fri, Oct 02, 2015 at 12:58:02AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > 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?
>
> As I described in the previous mail,
I meant: "How does the first kernel pass info to the capture kernel by
*not* using the kernel command line"?
The kernel command line is not the channel to pass data to the kdump
kernel.
> Yes, your first kernel doesn't get external NMIs, but basically
> you don't have to set "noextnmi" option to the first kernel.
So it doesn't belong there as a kernel command line parameter in the
first place.
IOW, you need a different method to pass data to the second kernel. Be
it an ELF header, be it a shared page, whatever.
--
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]
| From | 河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com> |
|---|---|
| Date | 2015-10-05 04:10 +0200 |
| Subject | RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option |
| Message-ID | <qg3nX-1K6-1@gated-at.bofh.it> |
| In reply to | #1238010 |
PiBPbiBGcmksIE9jdCAwMiwgMjAxNSBhdCAxMjo1ODowMkFNICswMDAwLCDmsrPlkIjoi7Hlro8g LyBLQVdBSe+8jEhJREVISVJPIHdyb3RlOg0KPiA+ID4gT24gVGh1LCBPY3QgMDEsIDIwMTUgYXQg MTA6MjQ6MTlBTSArMDAwMCwg5rKz5ZCI6Iux5a6PIC8gS0FXQUnvvIxISURFSElSTyB3cm90ZToN Cj4gPiA+ID4gQnV0IGhvdyBkbyB3ZSBjaGVjayBpZiB0aGUgc3RhcnRpbmcga2VybmVsIGlzIGEg ZHVtcCBjYXB0dXJlIGtlcm5lbD8NCj4gPiA+DQo+ID4gPiBIb3cgZG9lcyB0aGF0IGZpcnN0IGtl cm5lbCBwYXNzIGluZm8gdG8gdGhlIGNhcHR1cmUga2VybmVsPw0KPiA+DQo+ID4gQXMgSSBkZXNj cmliZWQgaW4gdGhlIHByZXZpb3VzIG1haWwsDQo+IA0KPiBJIG1lYW50OiAiSG93IGRvZXMgdGhl IGZpcnN0IGtlcm5lbCBwYXNzIGluZm8gdG8gdGhlIGNhcHR1cmUga2VybmVsIGJ5DQo+ICpub3Qq IHVzaW5nIHRoZSBrZXJuZWwgY29tbWFuZCBsaW5lIj8NCj4gDQo+IFRoZSBrZXJuZWwgY29tbWFu ZCBsaW5lIGlzIG5vdCB0aGUgY2hhbm5lbCB0byBwYXNzIGRhdGEgdG8gdGhlIGtkdW1wDQo+IGtl cm5lbC4NCg0KVGhhdCdzIGRpZmZlcmVudCBmcm9tIG15IHBvaW50IG9mIHZpZXcuICBJJ20gbm90 IGdvaW5nIHRvIHBhc3MNCnNvbWUgZGF0YSBmcm9tIHRoZSBmaXJzdCBrZXJuZWwgdG8gdGhlIHNl Y29uZCBrZXJuZWwuIEknbSBqdXN0IGdvaW5nIHRvDQpwcm92aWRlIGEgY29uZmlndXJhYmxlIG9w dGlvbiBmb3IgdGhlIHNlY29uZCBrZXJuZWwgdG8gdXNlcnMuDQoNCldlIHNvdWxkbid0IGVuYWJs ZSB0aGlzIGZlYXR1cmUgc2lsZW50bHkuICBTb21lIHVzZXJzIHdvdWxkbid0IGxpa2UNCnRvIGVu YWJsZSB0aGlzIGZlYXR1cmUuICBGb3IgZXhhbXBsZSwgYSB1c2VyIGVuYWJsZXMgYSB3YXRjaGRv ZyB0aW1lcg0Kd2hpY2ggcmFpc2VzIGFuIGV4dGVybmFsIE5NSSB3aGVuIHRoZSBjb3VudGVyIGlz IG5vdCByZXNldCBmb3IgYQ0Kc3BlY2lmaWMgZHVyYXRpb24uICBUaGVuLCB0aGUgc2Vjb25kIGtl cm5lbCBoYW5ncyB1cCB3aGlsZSBzYXZpbmcNCmNyYXNoIGR1bXAsIGFuZCBOTUkgaXMgZGVsaXZl cmVkIHRvIHRoZSBDUFUuICBUaGUga2VybmVsIGdldHMgcGFuaWMNCmR1ZSB0byB0aGUgTk1JLCBw cmludHMgc29tZSBpbmZvcm1hdGlvbiB0byB0aGUgZGlzcGxheSBhbmQgc2VyaWFsDQpjb25zb2xl LCBhbmQgdGhlbiBhdXRvbWF0aWNhbGx5IHJlYm9vdC4gIEluIHRoaXMgY2FzZSwgdXNlcnMgZG9u J3QNCndhbnQgdG8gYmxvY2sgZXh0ZXJuYWwgTk1Jcy4NCg0KU28sIG1ha2luZyB0aGlzIGZlYXR1 cmUgY29uZmlndXJhYmxlIGJ5IGNvbW1hbmQgbGluZSBvcHRpb24gaXMNCnJlYXNvbmFibGUuDQoN Cj4gPiBZZXMsIHlvdXIgZmlyc3Qga2VybmVsIGRvZXNuJ3QgZ2V0IGV4dGVybmFsIE5NSXMsIGJ1 dCBiYXNpY2FsbHkNCj4gPiB5b3UgZG9uJ3QgaGF2ZSB0byBzZXQgIm5vZXh0bm1pIiBvcHRpb24g dG8gdGhlIGZpcnN0IGtlcm5lbC4NCj4gDQo+IFNvIGl0IGRvZXNuJ3QgYmVsb25nIHRoZXJlIGFz IGEga2VybmVsIGNvbW1hbmQgbGluZSBwYXJhbWV0ZXIgaW4gdGhlDQo+IGZpcnN0IHBsYWNlLg0K PiANCj4gSU9XLCB5b3UgbmVlZCBhIGRpZmZlcmVudCBtZXRob2QgdG8gcGFzcyBkYXRhIHRvIHRo ZSBzZWNvbmQga2VybmVsLiBCZQ0KPiBpdCBhbiBFTEYgaGVhZGVyLCBiZSBpdCBhIHNoYXJlZCBw YWdlLCB3aGF0ZXZlci4NCg0KSSB0aGluayB3ZSBzaG91bGQgdXNlIHRoZSBFTEYgaGVhZGVyIG9u bHkgaWYgdGhlIHBhc3NlZCBpbmZvcm1hdGlvbg0KaXMgc2F2ZWQgdG8gYSBjcmFzaCBkdW1wLg0K DQpBbHNvLCB3ZSB3b3VsZG4ndCB3YW50IHRvIGludHJvZHVjZSBuZXcgc2hhcmVkIHBhZ2UgZm9y IHRoYXQgcHVycG9zZS4NCkEgbWVtb3J5IHNlZ21lbnQgcHJvdmlkZWQgYnkga2V4ZWMgc3lzY2Fs bCBpcyBub3QgdXNhYmxlIGJlY2F1c2UNCnRoZSBzZWNvbmQga2VybmVsIGRvZXNuJ3Qga25vdyB3 aGF0IHRoZXJlIGlzIGluIGEgc2VnbWVudCB3aXRob3V0IGENCmNvbW1hbmQgbGluZSBvcHRpb24u ICBQbGVhc2Ugbm90ZSB0aGF0ICJlbGZjb3JlaGRyIiBjb21tYW5kIGxpbmUgb3B0aW9uDQpwcmVw YXJlZCBieSBrZXhlYyBjb21tYW5kIGlzIHVzZWQgdG8gaW5mb3JtIHRoZSBzZWNvbmQga2VybmVs IGFib3V0DQp0aGUgYWRkcmVzcyBvZiB0aGUgRUxGIGhlYWRlciBtZW1vcnkgc2VnbWVudC4NCg0K UmVnYXJkcywNCg0KDQpIaWRlaGlybyBLYXdhaQ0KSGl0YWNoaSwgTHRkLiBSZXNlYXJjaCAmIERl dmVsb3BtZW50IEdyb3VwDQoNCg0K -- 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]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2015-10-05 10:30 +0200 |
| Subject | Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option |
| Message-ID | <qg9jI-1RW-1@gated-at.bofh.it> |
| In reply to | #1239252 |
On Mon, Oct 05, 2015 at 02:03:58AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> That's different from my point of view. I'm not going to pass
> some data from the first kernel to the second kernel. I'm just going to
> provide a configurable option for the second kernel to users.
Dude, WTF?! You're adding a kernel command line which is supposed to
be used *only* by the kdump kernel. But nooo, it is there in the open
and visible to people. And anyone can type it in during boot. AND THAT
SHOULDN'T BE POSSIBLE IN THE FIRST PLACE!
This information is strictly for the kdump kernel - it shouldn't be a
generic command line option. How hard it is to understand that simple
fact?!
<snip obvious use case>
> I think we should use the ELF header only if the passed information
> is saved to a crash dump.
So what?! ELF header will contain the additional bit of information that
the second kernel wasn't reacting to NMIs. But that's fine, that *is*
the desired behavior anyway.
All I'm saying is, this is a strict kdump kernel "command", so to speak,
and it doesn't belong with the generic kernel command line parameters.
--
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]
| From | 河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com> |
|---|---|
| Date | 2015-10-05 11:30 +0200 |
| Subject | RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option |
| Message-ID | <qgafM-3de-3@gated-at.bofh.it> |
| In reply to | #1239340 |
PiBPbiBNb24sIE9jdCAwNSwgMjAxNSBhdCAwMjowMzo1OEFNICswMDAwLCDmsrPlkIjoi7Hlro8g LyBLQVdBSe+8jEhJREVISVJPIHdyb3RlOg0KPiA+IFRoYXQncyBkaWZmZXJlbnQgZnJvbSBteSBw b2ludCBvZiB2aWV3LiAgSSdtIG5vdCBnb2luZyB0byBwYXNzDQo+ID4gc29tZSBkYXRhIGZyb20g dGhlIGZpcnN0IGtlcm5lbCB0byB0aGUgc2Vjb25kIGtlcm5lbC4gSSdtIGp1c3QgZ29pbmcgdG8N Cj4gPiBwcm92aWRlIGEgY29uZmlndXJhYmxlIG9wdGlvbiBmb3IgdGhlIHNlY29uZCBrZXJuZWwg dG8gdXNlcnMuDQo+IA0KPiBEdWRlLCBXVEY/ISBZb3UncmUgYWRkaW5nIGEga2VybmVsIGNvbW1h bmQgbGluZSB3aGljaCBpcyBzdXBwb3NlZCB0bw0KPiBiZSB1c2VkICpvbmx5KiBieSB0aGUga2R1 bXAga2VybmVsLiBCdXQgbm9vbywgaXQgaXMgdGhlcmUgaW4gdGhlIG9wZW4NCj4gYW5kIHZpc2li bGUgdG8gcGVvcGxlLiBBbmQgYW55b25lIGNhbiB0eXBlIGl0IGluIGR1cmluZyBib290LiBBTkQg VEhBVA0KPiBTSE9VTEROJ1QgQkUgUE9TU0lCTEUgSU4gVEhFIEZJUlNUIFBMQUNFIQ0KPiANCj4g VGhpcyBpbmZvcm1hdGlvbiBpcyBzdHJpY3RseSBmb3IgdGhlIGtkdW1wIGtlcm5lbCAtIGl0IHNo b3VsZG4ndCBiZSBhDQo+IGdlbmVyaWMgY29tbWFuZCBsaW5lIG9wdGlvbi4gSG93IGhhcmQgaXQg aXMgdG8gdW5kZXJzdGFuZCB0aGF0IHNpbXBsZQ0KPiBmYWN0PyENCg0KU28sIHRoZSBwcm9ibGVt IGZvciB5b3UgaXMgdGhhdCAibm9leHRubWkiIG9wdGlvbiBpcyB2aXNpYmxlIGFuZCBlZmZlY3Rp dmUNCmluIHRoZSBmaXJzdCBrZXJuZWwsIGlzbid0IGl0PyAgSWYgc28sIHdlIGNhbiBpZ25vcmUg Im5vZXh0bm1pIiBvcHRpb24NCmlmIHdlIGFyZSBpbiB0aGUgZmlyc3Qga2VybmVsIGFuZCByZW1v dmUgaXQgZnJvbSB0aGUgZG9jdW1lbnRhdGlvbi4NCiJlbGZjb3JlaGRyIiBjbWRsaW5lIG9wdGlv biBwcmVwYXJlZCBieSBrZXhlYyBjb21tYW5kIGlzIHBhc3NlZCB0byBvbmx5DQp0aGUgc2Vjb25k IGtlcm5lbCwgYW5kIGl0IGlzIGFsc28gdXNlZCB0byBjaGVjayBpZiB0aGUgYm9vdGVkIGtlcm5l bCBpcw0KYSBrZHVtcCBrZXJuZWwuICBUaHVzLCBpZiAiZWxmY29yZWhkciIgaXMgTk9UIHNwZWNp ZmllZCwgdGhlbiBpZ25vcmUNCiJub2V4dG5taSIuDQoNCkRvY3VtZW50YXRpb24va2VybmVsLXBh cmFtZXRlcnMudHh0Og0KPiAgICAgICAgIGVsZmNvcmVoZHI9W3NpemVbS01HXUBdb2Zmc2V0W0tN R10gW0lBNjQsUFBDLFNILFg4NixTMzkwXQ0KPiAgICAgICAgICAgICAgICAgICAgICAgICBTcGVj aWZpZXMgcGh5c2ljYWwgYWRkcmVzcyBvZiBzdGFydCBvZiBrZXJuZWwgY29yZQ0KPiAgICAgICAg ICAgICAgICAgICAgICAgICBpbWFnZSBlbGYgaGVhZGVyIGFuZCBvcHRpb25hbGx5IHRoZSBzaXpl LiBHZW5lcmFsbHkNCj4gICAgICAgICAgICAgICAgICAgICAgICAga2V4ZWMgbG9hZGVyIHdpbGwg cGFzcyB0aGlzIG9wdGlvbiB0byBjYXB0dXJlIGtlcm5lbC4NCj4gICAgICAgICAgICAgICAgICAg ICAgICAgU2VlIERvY3VtZW50YXRpb24va2R1bXAva2R1bXAudHh0IGZvciBkZXRhaWxzLg0KDQo+ IDxzbmlwIG9idmlvdXMgdXNlIGNhc2U+DQo+IA0KPiA+IEkgdGhpbmsgd2Ugc2hvdWxkIHVzZSB0 aGUgRUxGIGhlYWRlciBvbmx5IGlmIHRoZSBwYXNzZWQgaW5mb3JtYXRpb24NCj4gPiBpcyBzYXZl ZCB0byBhIGNyYXNoIGR1bXAuDQo+IA0KPiBTbyB3aGF0PyEgRUxGIGhlYWRlciB3aWxsIGNvbnRh aW4gdGhlIGFkZGl0aW9uYWwgYml0IG9mIGluZm9ybWF0aW9uIHRoYXQNCj4gdGhlIHNlY29uZCBr ZXJuZWwgd2Fzbid0IHJlYWN0aW5nIHRvIE5NSXMuIEJ1dCB0aGF0J3MgZmluZSwgdGhhdCAqaXMq DQo+IHRoZSBkZXNpcmVkIGJlaGF2aW9yIGFueXdheS4NCj4gDQo+IEFsbCBJJ20gc2F5aW5nIGlz LCB0aGlzIGlzIGEgc3RyaWN0IGtkdW1wIGtlcm5lbCAiY29tbWFuZCIsIHNvIHRvIHNwZWFrLA0K PiBhbmQgaXQgZG9lc24ndCBiZWxvbmcgd2l0aCB0aGUgZ2VuZXJpYyBrZXJuZWwgY29tbWFuZCBs aW5lIHBhcmFtZXRlcnMuDQoNClJlZ2FyZHMsDQoNCkhpZGVoaXJvIEthd2FpDQpIaXRhY2hpLCBM dGQuIFJlc2VhcmNoICYgRGV2ZWxvcG1lbnQgR3JvdXANCg0KDQoNCg== -- 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]
| From | Borislav Petkov <bp@alien8.de> |
|---|---|
| Date | 2015-10-05 12:20 +0200 |
| Subject | Re: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option |
| Message-ID | <qgb2b-4nd-31@gated-at.bofh.it> |
| In reply to | #1239381 |
On Mon, Oct 05, 2015 at 09:21:02AM +0000, 河合英宏 / KAWAI，HIDEHIRO wrote:
> So, the problem for you is that "noextnmi" option is visible and effective
> in the first kernel, isn't it?
No, such an option shouldn't exist at all. You should be passing
information *in* *a* *different* *manner* to the kdump kernel - not with
a kernel command line option.
I get the feeling I'm starting to sound like a broken record on this
mail thread... :-(
One other thing we could probably try to do is use boot_params which
is, IIUC, passed to the second kernel. So we can add another bit to
boot_params.hdr.loadflags or so and use that. Or something similar.
Not particularly crazy about it but it is still much better than a
command line param...
--
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]
| From | Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> |
|---|---|
| Date | 2015-09-25 14:10 +0200 |
| Subject | [V4 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context |
| Message-ID | <qczZ9-T1-31@gated-at.bofh.it> |
| In reply to | #1232738 |
nmi_shootdown_cpus(), a subroutine of crash_kexec(), sends NMI IPI
to non-panic cpus to stop them while saving their register
information and doing some cleanups for crash dumping. So if a
non-panic cpus is infinitely looping in NMI context, we fail to
save its register information and lose the information from the
crash dump.
`Infinite loop in NMI context' can happen when panic on NMI happens
while another cpu has already been processing panic(). To save
registers in that case too, this patch does following two things:
1. Move the timing of `infinite loop in NMI context' (actually
done by panic_smp_self_stop()) outside of panic() to enable us to
refer pt_regs
2. call a callback of nmi_shootdown_cpus() directly to save
registers and do some cleanups after setting waiting_for_crash_ipi
which is used for counting down the number of cpus which handled
the callback
V4:
- Rewrite the patch description
V3:
- Newly introduced
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: Eric Biederman <ebiederm@xmission.com>
Cc: Vivek Goyal <vgoyal@redhat.com>
Cc: Michal Hocko <mhocko@kernel.org>
---
arch/x86/kernel/nmi.c | 6 +++---
arch/x86/kernel/reboot.c | 11 +++++++++++
include/linux/kernel.h | 12 ++++++++++--
kernel/panic.c | 10 ++++++++++
kernel/watchdog.c | 5 +++--
5 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index 5131714..5e00de7 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)
- nmi_panic("NMI: Not continuing");
+ nmi_panic(regs, "NMI: Not continuing");
pr_emerg("Dazed and confused, but trying to continue\n");
@@ -256,7 +256,7 @@ void unregister_nmi_handler(unsigned int type, const char *name)
show_regs(regs);
if (panic_on_io_nmi) {
- nmi_panic("NMI IOCK error: Not continuing");
+ nmi_panic(regs, "NMI IOCK error: Not continuing");
/*
* If we return from nmi_panic(), it means we have received
@@ -305,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)
- nmi_panic("NMI: Not continuing");
+ nmi_panic(regs, "NMI: Not continuing");
pr_emerg("Dazed and confused, but trying to continue\n");
}
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 02693dd..d82259b 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -718,6 +718,7 @@ void machine_crash_shutdown(struct pt_regs *regs)
static nmi_shootdown_cb shootdown_callback;
static atomic_t waiting_for_crash_ipi;
+static int crash_ipi_done;
static int crash_nmi_callback(unsigned int val, struct pt_regs *regs)
{
@@ -779,6 +780,7 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback)
wmb();
smp_send_nmi_allbutself();
+ crash_ipi_done = 1; /* Kick cpus looping in nmi context */
msecs = 1000; /* Wait at most a second for the other cpus to stop */
while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
@@ -788,6 +790,15 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback)
/* Leave the nmi callback set */
}
+
+void nmi_panic_self_stop(struct pt_regs *regs)
+{
+ while (crash_ipi_done == 0)
+ cpu_relax();
+
+ crash_nmi_callback(0, regs); /* Shouldn't return */
+}
+
#else /* !CONFIG_SMP */
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
{
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 57c33da..9fe9961 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -255,6 +255,7 @@ static inline void might_fault(void) { }
__printf(1, 2)
void panic(const char *fmt, ...)
__noreturn __cold;
+void nmi_panic_self_stop(struct pt_regs *);
extern void oops_enter(void);
extern void oops_exit(void);
void print_oops_end_marker(void);
@@ -448,12 +449,19 @@ extern __scanf(2, 0)
/*
* A variant of panic() called from NMI context.
* If we've already panicked on this cpu, return from here.
+ * If another cpu already panicked, loop in nmi_panic_self_stop() which
+ * can provide architecture dependent code such as saving register states
+ * for crash dump.
*/
-#define nmi_panic(fmt, ...) \
+#define nmi_panic(regs, fmt, ...) \
do { \
+ int old_cpu; \
int this_cpu = raw_smp_processor_id(); \
- if (atomic_cmpxchg(&panic_cpu, -1, this_cpu) != this_cpu) \
+ old_cpu = atomic_cmpxchg(&panic_cpu, -1, this_cpu); \
+ if (old_cpu == -1) \
panic(fmt, ##__VA_ARGS__); \
+ else if (old_cpu != this_cpu) \
+ nmi_panic_self_stop(regs); \
} while (0)
/*
diff --git a/kernel/panic.c b/kernel/panic.c
index a105e67..cddbfe0 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -60,6 +60,16 @@ void __weak panic_smp_self_stop(void)
cpu_relax();
}
+/*
+ * Stop ourself in NMI context if another cpu has already panicked.
+ * Architecture code may override this to prepare for crash dumping
+ * (e.g. save register information).
+ */
+void __weak nmi_panic_self_stop(struct pt_regs *regs)
+{
+ panic_smp_self_stop();
+}
+
atomic_t panic_cpu = ATOMIC_INIT(-1);
/**
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index 00fbaa29..0074e5d 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -324,8 +324,9 @@ static void watchdog_overflow_callback(struct perf_event *event,
return;
if (hardlockup_panic)
- nmi_panic("Watchdog detected hard LOCKUP on cpu %d",
- this_cpu);
+ nmi_panic(regs,
+ "Watchdog detected hard LOCKUP on cpu %d",
+ this_cpu);
else
WARN(1, "Watchdog detected hard LOCKUP on cpu %d",
this_cpu);
--
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]
| From | Peter Zijlstra <peterz@infradead.org> |
|---|---|
| Date | 2015-09-30 14:00 +0200 |
| Subject | Re: [V4 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context |
| Message-ID | <qeodc-468-13@gated-at.bofh.it> |
| In reply to | #1232745 |
On Fri, Sep 25, 2015 at 08:28:07PM +0900, Hidehiro Kawai wrote:
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -718,6 +718,7 @@ void machine_crash_shutdown(struct pt_regs *regs)
> static nmi_shootdown_cb shootdown_callback;
>
> static atomic_t waiting_for_crash_ipi;
> +static int crash_ipi_done;
>
> static int crash_nmi_callback(unsigned int val, struct pt_regs *regs)
> {
> @@ -779,6 +780,7 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback)
> wmb();
>
> smp_send_nmi_allbutself();
> + crash_ipi_done = 1; /* Kick cpus looping in nmi context */
I would suggest using WRITE_ONCE() for that, because without the
volatile the compiler need not actually emit the store until after the
whole waiting thing _IF_ it can inline the whole thing.
Currently udelay() will end up being a function call and will therefore
force the store to be emitted, but I'd rather not rely on that.
>
> msecs = 1000; /* Wait at most a second for the other cpus to stop */
> while ((atomic_read(&waiting_for_crash_ipi) > 0) && msecs) {
--
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]
| From | 河合英宏 / KAWAI，HIDEHIRO <hidehiro.kawai.ez@hitachi.com> |
|---|---|
| Date | 2015-10-01 03:50 +0200 |
| Subject | RE: [V4 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context |
| Message-ID | <qeBap-5VD-5@gated-at.bofh.it> |
| In reply to | #1236212 |
PiBPbiBGcmksIFNlcCAyNSwgMjAxNSBhdCAwODoyODowN1BNICswOTAwLCBIaWRlaGlybyBLYXdh aSB3cm90ZToNCj4gPiAtLS0gYS9hcmNoL3g4Ni9rZXJuZWwvcmVib290LmMNCj4gPiArKysgYi9h cmNoL3g4Ni9rZXJuZWwvcmVib290LmMNCj4gPiBAQCAtNzE4LDYgKzcxOCw3IEBAIHZvaWQgbWFj aGluZV9jcmFzaF9zaHV0ZG93bihzdHJ1Y3QgcHRfcmVncyAqcmVncykNCj4gPiAgc3RhdGljIG5t aV9zaG9vdGRvd25fY2Igc2hvb3Rkb3duX2NhbGxiYWNrOw0KPiA+DQo+ID4gIHN0YXRpYyBhdG9t aWNfdCB3YWl0aW5nX2Zvcl9jcmFzaF9pcGk7DQo+ID4gK3N0YXRpYyBpbnQgY3Jhc2hfaXBpX2Rv bmU7DQo+ID4NCj4gPiAgc3RhdGljIGludCBjcmFzaF9ubWlfY2FsbGJhY2sodW5zaWduZWQgaW50 IHZhbCwgc3RydWN0IHB0X3JlZ3MgKnJlZ3MpDQo+ID4gIHsNCj4gPiBAQCAtNzc5LDYgKzc4MCw3 IEBAIHZvaWQgbm1pX3Nob290ZG93bl9jcHVzKG5taV9zaG9vdGRvd25fY2IgY2FsbGJhY2spDQo+ ID4gIAl3bWIoKTsNCj4gPg0KPiA+ICAJc21wX3NlbmRfbm1pX2FsbGJ1dHNlbGYoKTsNCj4gPiAr CWNyYXNoX2lwaV9kb25lID0gMTsgLyogS2ljayBjcHVzIGxvb3BpbmcgaW4gbm1pIGNvbnRleHQg Ki8NCj4gDQo+IEkgd291bGQgc3VnZ2VzdCB1c2luZyBXUklURV9PTkNFKCkgZm9yIHRoYXQsIGJl Y2F1c2Ugd2l0aG91dCB0aGUNCj4gdm9sYXRpbGUgdGhlIGNvbXBpbGVyIG5lZWQgbm90IGFjdHVh bGx5IGVtaXQgdGhlIHN0b3JlIHVudGlsIGFmdGVyIHRoZQ0KPiB3aG9sZSB3YWl0aW5nIHRoaW5n IF9JRl8gaXQgY2FuIGlubGluZSB0aGUgd2hvbGUgdGhpbmcuDQo+IA0KPiBDdXJyZW50bHkgdWRl bGF5KCkgd2lsbCBlbmQgdXAgYmVpbmcgYSBmdW5jdGlvbiBjYWxsIGFuZCB3aWxsIHRoZXJlZm9y ZQ0KPiBmb3JjZSB0aGUgc3RvcmUgdG8gYmUgZW1pdHRlZCwgYnV0IEknZCByYXRoZXIgbm90IHJl bHkgb24gdGhhdC4NCg0KT0ssIEkgdXNlIFdSSVRFX09OQ0UoKS4NClRoYW5rcyENCg0KPiA+DQo+ ID4gIAltc2VjcyA9IDEwMDA7IC8qIFdhaXQgYXQgbW9zdCBhIHNlY29uZCBmb3IgdGhlIG90aGVy IGNwdXMgdG8gc3RvcCAqLw0KPiA+ICAJd2hpbGUgKChhdG9taWNfcmVhZCgmd2FpdGluZ19mb3Jf Y3Jhc2hfaXBpKSA+IDApICYmIG1zZWNzKSB7DQoNCg0KSGlkZWhpcm8gS2F3YWkNCkhpdGFjaGks IEx0ZC4gUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBHcm91cA0KDQoNCg0K -- 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] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | linux.kernel
csiph-web