linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Vivek Goyal <vgoyal@redhat.com>,
	Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	linux-mips@linux-mips.org, Baoquan He <bhe@redhat.com>,
	linux-sh@vger.kernel.org, linux-s390@vger.kernel.org,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@kernel.org>,
	HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com>,
	Daniel Walker <dwalker@fifo99.com>,
	linuxppc-dev@lists.ozlabs.org, linux-metag@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: Re: [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option
Date: Wed, 15 Jul 2015 12:09:08 +0900	[thread overview]
Message-ID: <55A5CED4.7050400@hitachi.com> (raw)
In-Reply-To: <20150714144248.GC10792@redhat.com>

On 2015/07/14 23:42, Vivek Goyal wrote:
> On Fri, Jul 10, 2015 at 08:33:31PM +0900, Hidehiro Kawai wrote:
>> This patch fixes problems reported by Daniel Walker
>> (https://lkml.org/lkml/2015/6/24/44), and also replaces the bug fix
>> commits 5375b70 and f45d85f.
>>
>> If "crash_kexec_post_notifiers" boot option is specified,
>> other cpus are stopped by smp_send_stop() before entering
>> crash_kexec(), while usually machine_crash_shutdown() called by
>> crash_kexec() does that.  This behavior change leads two problems.
>>
>>  Problem 1:
>>  Some function in the crash_kexec() path depend on other cpus being
>>  still online.  If other cpus have been offlined already, they
>>  doesn't work properly.
>>
>>   Example:
>>    panic()
>>     crash_kexec()
>>      machine_crash_shutdown()
>>       octeon_generic_shutdown() // shutdown watchdog for ONLINE cpus
>>      machine_kexec()
>>
>>  Problem 2:
>>  Most of architectures stop other cpus in the machine_crash_shutdown()
>>  path and save register information at the same time.  However, if
>>  smp_send_stop() is called before that, we can't save the register
>>  information.
>>
>> To solve these problems, this patch changes the timing of calling
>> the callbacks instead of changing the timing of crash_kexec() if
>> crash_kexec_post_notifiers boot option is specified.
>>
>>  Before:
>>   if (!crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>   smp_send_stop()
>>   atomic_notifier_call_chain()
>>   kmsg_dump()
>>
>>   if (crash_kexec_post_notifiers)
>>       crash_kexec()
>>
>>  After:
>>   crash_kexec()
>>       machine_crash_shutdown()
>>       if (crash_kexec_post_notifiers) {
>>           atomic_notifier_call_chain()
>>           kmsg_dump()
>>       }
>>       machine_kexec()
>>
>>   smp_send_stop()
>>   if (!crash_kexec_post_notifiers) {
>>       atomic_notifier_call_chain()
>>       kmsg_dump()
>>   }
>>
> 
> I think this new code flow looks bad. Now we are calling kmsg_dump()
> and atomic_notifier_call_chain() from inside the crash_kexec() as well
> as from inside panic(). This is bad.
> 
> So basic problem seems to be that cpus need to be stopped once (with
> or without panic notifiers. So why don't we look into desiginig a 
> function which stops cpus, saves register states first and then does
> rest of the processing.
> 
> Something like.
> 
> stop_cpus_save_register_state;
> 
> if (!crash_kexec_post_notifiers)
> 	crash_kexec()
> 
> atomic_notifier_call_chain()
> kmsg_dump()
> 
> Here crash_kexec() will have to be modified and it will assume that cpus
> have already been stopped and register states have already been saved.

Ah, nice! I like this idea :)

> 
> IOW, is there a reason that we can't get rid of smp_send_stop() and
> use the mechanism crash_kexec() is using to stop cpus after panic()?

I think there is no reason why we don't do so. smp_send_stop() just
stops other cpus, but crash's one does more (collect registers and
stop watchdogs if needed, etc.). why don't we just replace(improve) it?

Thank you!


-- 
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com

  reply	other threads:[~2015-07-15  3:09 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-10 11:33 [PATCH 0/3] kexec: crash_kexec_post_notifiers boot option related fixes Hidehiro Kawai
2015-07-10 11:33 ` [PATCH 1/3] panic: Disable crash_kexec_post_notifiers if kdump is not available Hidehiro Kawai
2015-07-10 13:41   ` Eric W. Biederman
2015-07-13 20:26     ` dwalker
2015-07-14  1:19       ` Eric W. Biederman
2015-07-14 13:59         ` dwalker
2015-07-14 14:20           ` Vivek Goyal
2015-07-14 15:02           ` Vivek Goyal
2015-07-14 15:34             ` dwalker
2015-07-14 15:40               ` Vivek Goyal
2015-07-14 15:48                 ` dwalker
2015-07-14 16:16                   ` Vivek Goyal
2015-07-14 17:06                     ` Eric W. Biederman
2015-07-14 17:29                       ` dwalker
2015-07-14 17:55                         ` Vivek Goyal
2015-07-14 18:01                           ` Eric W. Biederman
2015-07-14 18:23                             ` Vivek Goyal
2015-07-15  5:16                               ` Masami Hiramatsu
2015-07-15 10:49                 ` Hidehiro Kawai
2015-07-14  1:56       ` Hidehiro Kawai
2015-07-10 11:33 ` [PATCH 3/3] kexec: Change the timing of callbacks related to "crash_kexec_post_notifiers" boot option Hidehiro Kawai
2015-07-14 14:42   ` Vivek Goyal
2015-07-15  3:09     ` Masami Hiramatsu [this message]
2015-07-10 11:33 ` [PATCH 2/3] kexec: Pass panic message to crash_kexec() Hidehiro Kawai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55A5CED4.7050400@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=d.hatayama@jp.fujitsu.com \
    --cc=dwalker@fifo99.com \
    --cc=ebiederm@xmission.com \
    --cc=hidehiro.kawai.ez@hitachi.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-metag@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mingo@kernel.org \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).