Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1191421 > unrolled thread

[RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

Back to article view | Back to linux.kernel

Contents

  [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option  related fixes Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> - 2015-07-24 03:30 +0200
    Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot  option related fixes Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> - 2015-08-03 13:10 +0200
      Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes ebiederm@xmission.com (Eric W. Biederman) - 2015-08-03 18:40 +0200
        RE: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot  option related fixes 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-08-04 13:50 +0200
          Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes ebiederm@xmission.com (Eric W. Biederman) - 2015-08-05 19:20 +0200
            RE: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot  option related fixes 河合英宏 / KAWAI，HIDEHIRO   <hidehiro.kawai.ez@hitachi.com> - 2015-08-07 03:40 +0200

#1191421 — [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

This is a bugfix patch for crash_kexec_post_notifiers boot option
which allows users to call panic notifiers and kmsg dumpers before
kdump.

This fixes one of the problems reported by Daniel Walker
(https://lkml.org/lkml/2015/6/24/44). 

 Problem 1:
 If crash_kexec_post_notifiers boot option is specified, some
 shutting down process which assume other cpus are still alive
 don't work properly.

 Problem 2 (addressed by this patch):
 If crash_kexec_post_notifiers boot option is specified, register
 information of other cpus are not saved to crash dumps.

Following Vivek's opinion, this patch replaces smp_send_stop()
in panic() with suitable version for crash_kexec which saves
cpu states and other things like cleaning up VMX/SVM.  Since this
needs architecture specific implementation and it's not so trivial,
this version only support for x86.  So the problem 1, known to
happen on MIPS/OCTEON, is not addressed now.

To keep the modification impact low, this patch doesn't change
the logic basically if crash_kexec_post_notifiers is not specified.

Please note that crash_kexec() can be called directly without
entering panic().  Stopping other cpus functionality is still
needed in crash_kexec().

Changes in V2:
- Replace smp_send_stop() call with crash_kexec version which
  saves cpu states and does cleanups instead of changing execution
  flow
- Drop a fix for Problem 1
- Drop other patches because they aren't needed anymore

V1: https://lkml.org/lkml/2015/7/10/316

---

Hidehiro Kawai (1):
      panic/x86: Replace smp_send_stop() with crash_kexec version


 arch/x86/kernel/crash.c |   16 +++++++++++-----
 kernel/panic.c          |   29 +++++++++++++++++++++++------
 2 files changed, 34 insertions(+), 11 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]

#1198744 — Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

Hello Eric and Vivek,

Do you have any comments?

(2015/07/24 10:16), Hidehiro Kawai wrote:
> This is a bugfix patch for crash_kexec_post_notifiers boot option
> which allows users to call panic notifiers and kmsg dumpers before
> kdump.
> 
> This fixes one of the problems reported by Daniel Walker
> (https://lkml.org/lkml/2015/6/24/44). 
> 
>  Problem 1:
>  If crash_kexec_post_notifiers boot option is specified, some
>  shutting down process which assume other cpus are still alive
>  don't work properly.
> 
>  Problem 2 (addressed by this patch):
>  If crash_kexec_post_notifiers boot option is specified, register
>  information of other cpus are not saved to crash dumps.
> 
> Following Vivek's opinion, this patch replaces smp_send_stop()
> in panic() with suitable version for crash_kexec which saves
> cpu states and other things like cleaning up VMX/SVM.  Since this
> needs architecture specific implementation and it's not so trivial,
> this version only support for x86.  So the problem 1, known to
> happen on MIPS/OCTEON, is not addressed now.
> 
> To keep the modification impact low, this patch doesn't change
> the logic basically if crash_kexec_post_notifiers is not specified.
> 
> Please note that crash_kexec() can be called directly without
> entering panic().  Stopping other cpus functionality is still
> needed in crash_kexec().
> 
> Changes in V2:
> - Replace smp_send_stop() call with crash_kexec version which
>   saves cpu states and does cleanups instead of changing execution
>   flow
> - Drop a fix for Problem 1
> - Drop other patches because they aren't needed anymore
> 
> V1: https://lkml.org/lkml/2015/7/10/316
> 
> ---
> 
> Hidehiro Kawai (1):
>       panic/x86: Replace smp_send_stop() with crash_kexec version
> 
> 
>  arch/x86/kernel/crash.c |   16 +++++++++++-----
>  kernel/panic.c          |   29 +++++++++++++++++++++++------
>  2 files changed, 34 insertions(+), 11 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] | [prev] | [next] | [standalone]

#1199030 — Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> writes:

> Hello Eric and Vivek,
>
> Do you have any comments?

crash_kexec_post_notifiers is a debugging hack to allow people to test
if the kmsg_dump works better than kexec.  crash_kexec_post_notifiers is
not, nor has it ever been a solution for general operation (which is
what I perceive this work trying to push).

I will not support any work that expands crash_kexec_post_notifiers to
be more than it currently is, because people want ``panic hooks'' to
run before kexec.  That appropach was extensively tested before kexec on
panic was implemented in the kernel and every implementation failed.
The practical symptom was that everything would work ok in testing but
on failures in the real world there would be enough going on in the
dying kernel that no crash dump would be taken.  kexec on panic on the
other hand works a reasonable fraction of the time.

I deeply and fundamentally can not support a general purpose hook being
called before kexec.  In 15 years of practice I have never heard of a
case where using a general purpose hook does anything but make kexec on
panic undebuggable in practice.

A specific hook for a very specific purpose when there is no other way
we can consider.

If you don't have something that generalises well into a general purpose
operation that it makes sense for everyone to call you can always use
the world's largest aka you can run code before the new kernel starts
that is loaded with kexec_load.

If you absolutely must run code in the dying code because you need lots
of the kernel infrastructure to work, and it is too hard to code a small
little bit of stand-alone assembly, I am sorry for you.  Experience shows
that will never work when the kernel fails in interesting ways.

So no.  I don't think there is any point to putting any more effort into
the crash_kexec_post_notifiers path because experience has shown over
the years that in practice it won't work for anyone, and if the code
doesn't work in practice there is no point in developing or implementing
it.

Eric
--
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]

#1199700 — RE: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

SGVsbG8sDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5Lg0KDQo+IEZyb206IEVyaWMgVy4gQmllZGVy
bWFuIFttYWlsdG86ZWJpZWRlcm1AeG1pc3Npb24uY29tXQ0KWy4uLl0NCj4gQSBzcGVjaWZpYyBo
b29rIGZvciBhIHZlcnkgc3BlY2lmaWMgcHVycG9zZSB3aGVuIHRoZXJlIGlzIG5vIG90aGVyIHdh
eQ0KPiB3ZSBjYW4gY29uc2lkZXIuDQoNClNvLCBpcyBrbXNnX2R1bXAgbGlrZSBmZWF0dXJlIGFk
bWlzc2libGU/DQoNCj4gSWYgeW91IGRvbid0IGhhdmUgc29tZXRoaW5nIHRoYXQgZ2VuZXJhbGlz
ZXMgd2VsbCBpbnRvIGEgZ2VuZXJhbCBwdXJwb3NlDQo+IG9wZXJhdGlvbiB0aGF0IGl0IG1ha2Vz
IHNlbnNlIGZvciBldmVyeW9uZSB0byBjYWxsIHlvdSBjYW4gYWx3YXlzIHVzZQ0KPiB0aGUgd29y
bGQncyBsYXJnZXN0IGFrYSB5b3UgY2FuIHJ1biBjb2RlIGJlZm9yZSB0aGUgbmV3IGtlcm5lbCBz
dGFydHMNCj4gdGhhdCBpcyBsb2FkZWQgd2l0aCBrZXhlY19sb2FkLg0KDQpPbmUgb2Ygb3VyIHB1
cnBvc2VzLCBub3RpZnlpbmcgIkknbSBkeWluZyIsIHdvdWxkIGJlIGFjaGlldmVkIGJ5IHB1cmdh
dG9yeQ0KY29kZSBwcm92aWRlZCBieSBrZXhlYyBjb21tYW5kIGFzIEkgc3RhdGVkIGJlZm9yZS4g
IFNpbmNlIHRoZSB3YXkgb2YgdGhlDQpub3RpZmljYXRpb24gd2lsbCBkaWZmZXIgZnJvbSBlYWNo
IHZlbmRvciwgSSB0aGluayB3ZSBuZWVkIHRvIG1vZGlmeQ0KdGhlIHB1cmdhdG9yeSBjb2RlcyBw
bHVnZ2FibGUuICBBbHNvLCBJIHRoaW5rIHdlIG5lZWQgc29tZSBwYXJhbWV0ZXINCnBhc3Npbmcg
bWVjaGFuaXNtIHRvIHRoZSBwdXJnYXRvcnkgY29kZS4gIEZvciBleGFtcGxlLCBwYXNzaW5nIHRo
ZSBwYW5pYw0KbWVzc2FnZSB2aWEgYm9vdCBwYXJhbWV0ZXIgdG8gc2F2ZSBpdCB0byBTRUwuICBB
bHRob3VnaCBJJ20gbm90IHN1cmUNCndlIGNhbiBkbyB0aGF0IChJJ3ZlIG5vdCBpbnZlc3RpZ2F0
ZWQgd2VsbCB5ZXQpLiAgSXMgdGhhdCBhY2NlcHRhYmxlPw0KDQpSZWdhcmRzLA0KS2F3YWkNCg0K
--
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]

#1201006 — Re: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

"河合英宏 / KAWAI，HIDEHIRO"  <hidehiro.kawai.ez@hitachi.com> writes:

> Hello,
>
> Thanks for the reply.
>
>> From: Eric W. Biederman [mailto:ebiederm@xmission.com]
> [...]
>> A specific hook for a very specific purpose when there is no other way
>> we can consider.
>
> So, is kmsg_dump like feature admissible?
>
>> If you don't have something that generalises well into a general purpose
>> operation that it makes sense for everyone to call you can always use
>> the world's largest aka you can run code before the new kernel starts
>> that is loaded with kexec_load.
>
> One of our purposes, notifying "I'm dying", would be achieved by purgatory
> code provided by kexec command as I stated before.  Since the way of the
> notification will differ from each vendor, I think we need to modify
> the purgatory codes pluggable.  Also, I think we need some parameter
> passing mechanism to the purgatory code.  For example, passing the panic
> message via boot parameter to save it to SEL.  Although I'm not sure
> we can do that (I've not investigated well yet).  Is that acceptable?

I think the address of panic message is available in crash notes.  If
not that is very reasonable to add.

Updating the SEL from purgatory after purgatory has validated the
checksums of the crash handling code is acceptable.

All that is desired is to run as little code as possible in a kernel
that is known broken.  Once the checksums have verified things in
purgatory you should be in good shape, and there is no possibility of
relying on broken infrastructure because that code simply is not present
in purgatory.

We already have a few early_printk style drivers in purgatory and I
don't the code to update the SEL would be much worse.

On the flip side there are enough firmware bugs that I personally would
not want to rely on firmware code running properly when the machine is
in a known broken state, so I don't want the SEL update to be
unconditional.

Eric


--
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]

#1202191 — RE: [RFC V2 PATCH 0/1] kexec: crash_kexec_post_notifiers boot option related fixes

PiBGcm9tOiBFcmljIFcuIEJpZWRlcm1hbiBbbWFpbHRvOmViaWVkZXJtQHhtaXNzaW9uLmNvbV0N
Cj4gPj4gRnJvbTogRXJpYyBXLiBCaWVkZXJtYW4gW21haWx0bzplYmllZGVybUB4bWlzc2lvbi5j
b21dDQo+ID4gWy4uLl0NCj4gPj4gQSBzcGVjaWZpYyBob29rIGZvciBhIHZlcnkgc3BlY2lmaWMg
cHVycG9zZSB3aGVuIHRoZXJlIGlzIG5vIG90aGVyIHdheQ0KPiA+PiB3ZSBjYW4gY29uc2lkZXIu
DQo+ID4NCj4gPiBTbywgaXMga21zZ19kdW1wIGxpa2UgZmVhdHVyZSBhZG1pc3NpYmxlPw0KPiA+
DQo+ID4+IElmIHlvdSBkb24ndCBoYXZlIHNvbWV0aGluZyB0aGF0IGdlbmVyYWxpc2VzIHdlbGwg
aW50byBhIGdlbmVyYWwgcHVycG9zZQ0KPiA+PiBvcGVyYXRpb24gdGhhdCBpdCBtYWtlcyBzZW5z
ZSBmb3IgZXZlcnlvbmUgdG8gY2FsbCB5b3UgY2FuIGFsd2F5cyB1c2UNCj4gPj4gdGhlIHdvcmxk
J3MgbGFyZ2VzdCBha2EgeW91IGNhbiBydW4gY29kZSBiZWZvcmUgdGhlIG5ldyBrZXJuZWwgc3Rh
cnRzDQo+ID4+IHRoYXQgaXMgbG9hZGVkIHdpdGgga2V4ZWNfbG9hZC4NCj4gPg0KPiA+IE9uZSBv
ZiBvdXIgcHVycG9zZXMsIG5vdGlmeWluZyAiSSdtIGR5aW5nIiwgd291bGQgYmUgYWNoaWV2ZWQg
YnkgcHVyZ2F0b3J5DQo+ID4gY29kZSBwcm92aWRlZCBieSBrZXhlYyBjb21tYW5kIGFzIEkgc3Rh
dGVkIGJlZm9yZS4gIFNpbmNlIHRoZSB3YXkgb2YgdGhlDQo+ID4gbm90aWZpY2F0aW9uIHdpbGwg
ZGlmZmVyIGZyb20gZWFjaCB2ZW5kb3IsIEkgdGhpbmsgd2UgbmVlZCB0byBtb2RpZnkNCj4gPiB0
aGUgcHVyZ2F0b3J5IGNvZGVzIHBsdWdnYWJsZS4gIEFsc28sIEkgdGhpbmsgd2UgbmVlZCBzb21l
IHBhcmFtZXRlcg0KPiA+IHBhc3NpbmcgbWVjaGFuaXNtIHRvIHRoZSBwdXJnYXRvcnkgY29kZS4g
IEZvciBleGFtcGxlLCBwYXNzaW5nIHRoZSBwYW5pYw0KPiA+IG1lc3NhZ2UgdmlhIGJvb3QgcGFy
YW1ldGVyIHRvIHNhdmUgaXQgdG8gU0VMLiAgQWx0aG91Z2ggSSdtIG5vdCBzdXJlDQo+ID4gd2Ug
Y2FuIGRvIHRoYXQgKEkndmUgbm90IGludmVzdGlnYXRlZCB3ZWxsIHlldCkuICBJcyB0aGF0IGFj
Y2VwdGFibGU/DQo+IA0KPiBJIHRoaW5rIHRoZSBhZGRyZXNzIG9mIHBhbmljIG1lc3NhZ2UgaXMg
YXZhaWxhYmxlIGluIGNyYXNoIG5vdGVzLiAgSWYNCj4gbm90IHRoYXQgaXMgdmVyeSByZWFzb25h
YmxlIHRvIGFkZC4NCg0KSSBiZWxpZXZlZCB0aGUgYm9vdCBwYXJhbWV0ZXIgaXMgcHJlcGFyZWQg
YnkgdGhlIDFzdCBrZXJuZWwsIGJ1dA0KaXQncyB3cm9uZy4gIFRoZSBib290IHBhcmFtZXRlciBp
cyBjb21wbGV0ZWx5IHByb3ZpZWRlZCBrZXhlYyBjb21tYW5kLg0KU28sIHBhc3NpbmcgdGhlIHBh
bmljIG1lc3NhZ2UgdGhyb3VnaCBib290IHBhcmFtZXRlciB3aWxsIG5vdA0KYmUgZmVhc2libGUu
ICBJJ20gbm90IHN1cmUgd2UgY2FuIGVhc2lseSBhY2Nlc3MgdG8gdGhlIGNyYXNoIG5vdGVzDQpm
cm9tIHB1cmdhdG9yeSwgYnV0IEkgdGhpbmsgaXQncyBhIHJlYXNvbmFibGUgd2F5IHRvIHBhc3Mg
cGFuaWMgbWVzc2FnZS4NCg0KPiBVcGRhdGluZyB0aGUgU0VMIGZyb20gcHVyZ2F0b3J5IGFmdGVy
IHB1cmdhdG9yeSBoYXMgdmFsaWRhdGVkIHRoZQ0KPiBjaGVja3N1bXMgb2YgdGhlIGNyYXNoIGhh
bmRsaW5nIGNvZGUgaXMgYWNjZXB0YWJsZS4NCj4gDQo+IEFsbCB0aGF0IGlzIGRlc2lyZWQgaXMg
dG8gcnVuIGFzIGxpdHRsZSBjb2RlIGFzIHBvc3NpYmxlIGluIGEga2VybmVsDQo+IHRoYXQgaXMg
a25vd24gYnJva2VuLiAgT25jZSB0aGUgY2hlY2tzdW1zIGhhdmUgdmVyaWZpZWQgdGhpbmdzIGlu
DQo+IHB1cmdhdG9yeSB5b3Ugc2hvdWxkIGJlIGluIGdvb2Qgc2hhcGUsIGFuZCB0aGVyZSBpcyBu
byBwb3NzaWJpbGl0eSBvZg0KPiByZWx5aW5nIG9uIGJyb2tlbiBpbmZyYXN0cnVjdHVyZSBiZWNh
dXNlIHRoYXQgY29kZSBzaW1wbHkgaXMgbm90IHByZXNlbnQNCj4gaW4gcHVyZ2F0b3J5Lg0KPiAN
Cj4gV2UgYWxyZWFkeSBoYXZlIGEgZmV3IGVhcmx5X3ByaW50ayBzdHlsZSBkcml2ZXJzIGluIHB1
cmdhdG9yeSBhbmQgSQ0KPiBkb24ndCB0aGUgY29kZSB0byB1cGRhdGUgdGhlIFNFTCB3b3VsZCBi
ZSBtdWNoIHdvcnNlLg0KDQpGb3IgZGV2ZWxvcGVycywgZWFybHlfcHJpbnRrIHN0eWxlIGZlYXR1
cmUgd2lsbCBiZSBiZXR0ZXIgc29sdXRpb24uDQpGb3IgZW5kIHVzZXJzLCBob3dldmVyLCBpdCB3
aWxsIG5vdCBiZSB0cnVlLiAgU29tZXRpbWVzIHRoZXkgY2Fubm90DQp1c2UgYSBzZXJpYWwgcG9y
dCBmb3IgZWFybHlfcHJpbnRrIGJlY2F1c2UgdGhlIHNlcmlhbCBwb3J0IGlzIHVzZWQNCmZvciBv
dGhlciBwdXJwb3NlLiAgU29tZXRpbWVzIHRoZXkgY2Fubm90IHBsYWNlIGFkZGl0aW9uYWwgbWFj
aGluZQ0Kd2hpY2ggcmVjZWl2ZXMgbWVzc2FnZXMgZnJvbSB0aGUgc2VyaWFsIHBvcnQuICBTbyB3
ZSBuZWVkIHNvbWUNCnBsdWdpbiBvciBlbmFibGUvZGlzYWJsZSBtZWNoYW5pc20gZm9yIHNwZWNp
ZmljIHB1cmdhdG9yeSBjb2RlLg0KDQo+IE9uIHRoZSBmbGlwIHNpZGUgdGhlcmUgYXJlIGVub3Vn
aCBmaXJtd2FyZSBidWdzIHRoYXQgSSBwZXJzb25hbGx5IHdvdWxkDQo+IG5vdCB3YW50IHRvIHJl
bHkgb24gZmlybXdhcmUgY29kZSBydW5uaW5nIHByb3Blcmx5IHdoZW4gdGhlIG1hY2hpbmUgaXMN
Cj4gaW4gYSBrbm93biBicm9rZW4gc3RhdGUsIHNvIEkgZG9uJ3Qgd2FudCB0aGUgU0VMIHVwZGF0
ZSB0byBiZQ0KPiB1bmNvbmRpdGlvbmFsLg0KDQpZZXMsIEkgZG9uJ3QgYWxzbyB0cnVzdCBCTUMg
ZmlybXdhcmUuICBUaGUgbW9zdCBzaW1wbGUgSS9GIHRvIEJNQw0KaXMgS0NTIChLZXlib2FyZCBD
b250cm9sbGVyIFN0eWxlKSBJL0Ygd2hpY2ggaXMgYWNjZXNzaWJsZSB2aWENCnR3byBJL08gcG9y
dHMuICBJZiBCTUMgYmVjb21lcyBpbnNhbmUsIHRoZSBzdGF0ZSBtYWNoaW5lIGZvciB0aGUgSS9G
DQpjYW4gZ28gaW50byBpbmZpbml0ZSBsb29wLiAgSG93ZXZlciwgd2UgY2FuIGF2b2lkIHRoaXMg
YnkgaW50cm9kdWNpbmcNCnByb3BlciB0aW1lb3V0LiAgT2YgY291cnNlLCBJIHRoaW5rIHdlIHNo
b3VsZCBhZGQgc29tZSBlbmFibGUvZGlzYWJsZQ0KbWVjaGFuaXNtLg0KDQoNClJlZ2FyZHMsDQpL
YXdhaQ0KDQo=
--
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]

Back to top | Article view | linux.kernel

csiph-web