All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Gong <gong.chen@linux.intel.com>
To: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Don Zickus <dzickus@redhat.com>,
	"Luck, Tony" <tony.luck@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Matthew Garrett <mjg@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
	"Chen, Gong" <gong.chen@intel.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"Brown, Len" <len.brown@intel.com>,
	"'ying.huang@intel.com'" <'ying.huang@intel.com'>,
	"'ak@linux.intel.com'" <'ak@linux.intel.com'>,
	"'hughd@chromium.org'" <'hughd@chromium.org'>,
	"'mingo@elte.hu'" <'mingo@elte.hu'>,
	"jmorris@namei.org" <jmorris@namei.org>,
	"a.p.zijlstra@chello.nl" <a.p.zijlstra@chello.nl>,
	"namhyung@gmail.com" <namhyung@gmail.com>,
	"dle-develop@lists.sourceforge.net" 
	<dle-develop@lists.sourceforge.net>,
	Satoru Moriya <satoru.moriya@hds.com>
Subject: Re: [RFC][PATCH v4 -next 1/4] Move kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop()
Date: Tue, 10 Jan 2012 11:06:27 +0800	[thread overview]
Message-ID: <4F0BAB33.2090201@linux.intel.com> (raw)
In-Reply-To: <5C4C569E8A4B9B42A84A977CF070A35B2C5827BBD8@USINDEVS01.corp.hds.com>

于 2012/1/10 1:59, Seiji Aguchi 写道:
>>
>> I don't know how to prove something is hardened other than not seeing any
>> hangs or false reboots on in that piece of code.
>>
>
> I don't know how we can prove reliability of smp_send_stop() of all archs as well.
>
> Another possible solution is replacing smp_send_stop() with
> machine_crash_shutdown().
> This is a function call stopping other cpus reliably in panic situation
> so that kdump can work .
> But, I don't know whether it works in all archs.

machine_crash_shutdown is defined in only some Archs so it is obvious that it
can't be used in all platforms, BTW, this function is bracketed by CONFIG_KEXEC,
which means it can't be used without this macro. So it is not suitable for
this scenario.

> We need further discussion with Eric for checking this idea is feasible...
>
>
> I would like to go forward step by step rather than doing tough work at once.
> I think just moving kmsg_dump() below smp_send_stop() is a good start for improving pstore.

I agree with you. How about adding macros or something like WARN_ON(XX_ARCH) or
Kconfig to limit its scope?


  reply	other threads:[~2012-01-10  3:06 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-05 17:35 [RFC][PATCH v4 -next 0/4] Make pstore/kmsg_dump run after stopping other cpus in panic path Seiji Aguchi
2012-01-05 17:36 ` [RFC][PATCH v4 -next 1/4] Move kmsg_dump(KMSG_DUMP_PANIC) below smp_send_stop() Seiji Aguchi
2012-01-05 19:06   ` Luck, Tony
2012-01-05 20:10     ` Seiji Aguchi
2012-01-05 21:01       ` Don Zickus
2012-01-09 17:59         ` Seiji Aguchi
2012-01-10  3:06           ` Chen Gong [this message]
2012-01-10 20:29             ` Seiji Aguchi
2012-01-11  7:28               ` Chen Gong
2012-01-11 17:25                 ` Don Zickus
2012-01-11 22:22                   ` Luck, Tony
2012-01-13 22:50                     ` Seiji Aguchi
     [not found]                     ` <32727E9A83EE9A42A1F0906295A3A77B2C78F49973@USINDEVS01.corp.hds.com>
2012-01-19 20:58                       ` Seiji Aguchi
2012-01-20 17:56                         ` Luck, Tony
2012-02-03 17:18                           ` Don Zickus
2012-02-03 22:32                             ` Luck, Tony
2012-02-03 22:57                               ` Don Zickus
2012-02-08 20:19                                 ` Don Zickus
2012-02-08 21:28                                   ` Luck, Tony
2012-02-08 22:48                                     ` Don Zickus
2012-02-08 22:56                                       ` Seiji Aguchi
2012-01-05 17:38 ` [RFC][PATCH v4 -next 2/4] Skip spin_locks in panic case and Add WARN_ON() Seiji Aguchi
2012-01-05 17:39 ` [RFC][PATCH v4 -next 3/4]Skip subsequent kmsg_dump() function calls in panic path Seiji Aguchi
2012-01-05 17:41 ` [RFC][PATCH v4 -next 4/4] Skip spin_lock of efi_pstore_write() in panic case Seiji Aguchi

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=4F0BAB33.2090201@linux.intel.com \
    --to=gong.chen@linux.intel.com \
    --cc='ak@linux.intel.com' \
    --cc='hughd@chromium.org' \
    --cc='mingo@elte.hu' \
    --cc='ying.huang@intel.com' \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=dzickus@redhat.com \
    --cc=gong.chen@intel.com \
    --cc=jmorris@namei.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg@redhat.com \
    --cc=namhyung@gmail.com \
    --cc=satoru.moriya@hds.com \
    --cc=seiji.aguchi@hds.com \
    --cc=tony.luck@intel.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.