public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: "akpm\@linux-foundation.org" <akpm@linux-foundation.org>,
	"xiyou.wangcong\@gmail.com" <xiyou.wangcong@gmail.com>,
	"paulmck\@linux.vnet.ibm.com" <paulmck@linux.vnet.ibm.com>,
	"simon.kagstrom\@netinsight.net" <simon.kagstrom@netinsight.net>,
	"kexec\@lists.infradead.org" <kexec@lists.infradead.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Satoru Moriya <satoru.moriya@hds.com>,
	"dle-develop\@lists.sourceforge.net" 
	<dle-develop@lists.sourceforge.net>,
	"David.Woodhouse\@intel.com" <David.Woodhouse@intel.com>,
	"anton\@samba.org" <anton@samba.org>,
	"ben\@decadent.org.uk" <ben@decadent.org.uk>,
	"randy.dunlap\@oracle.com" <randy.dunlap@oracle.com>,
	"jason.wessel\@windriver.com" <jason.wessel@windriver.com>
Subject: Re: [RFC][PATCH] Fix kexec abort due to IPI from panic().
Date: Mon, 27 Sep 2010 09:59:28 -0700	[thread overview]
Message-ID: <m1eicfp1fz.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <5C4C569E8A4B9B42A84A977CF070A35B2C0DCFFB3E@USINDEVS01.corp.hds.com> (Seiji Aguchi's message of "Fri, 24 Sep 2010 09:08:14 -0400")

Seiji Aguchi <seiji.aguchi@hds.com> writes:

> Hi Eric,
>
> This is a patch which makes kmsg_dump() non-blocking.
> Please give me your comments and suggestions.
>
> I improved it as follows.
>
> (1) Improvement of dump_list_lock
>     (1-1) I changed dump_list to RCU for deleting dump_list_lock in kmsg_dump().
>     (1-2) I moved kmsg_dump(KMSG_DUMP_KEXEC) behind machine_crash_shutdown() 
>           for avoiding concurrent execution of dump_list functions.
>     (1-3) I also moved kmsg_dump(KMSG_DUMP_PANIC) behind smp_send_stop() for the 
>           same reason.
>  
> (2) Improvement of logbuf_lock
>     I added spinlock_init(&logbuf_lock) when executing kmsg_dump() in kexec or panic path
>     for preventing dead lock.
>
> We can delete blocking kmsg_dump call in crash_kexec and panic path.

This looks better, but it still gives me the willies.

I tried tracing through the ramoops code to see if there were anything
else that could block, but I couldn't make it through do_gettimeofday.

I couldn't even make it that far with the mtd oops tracer.

The fact that the code is exported and modular doesn't make me feel
safe because there have been people in the past who have asked for an
notifier on crash so they could do stupid things when the kernel is
broken.

The fact that this wasn't noticed until we actually had a hang, doesn't
give me an especially great feeling about long term stability.

Most of all I don't see the use case of calling kmsg_dump when you have
kexec on panic setup to do the same thing.  Having kmsg_dump not on
the kexec on panic code path would let me sleep much easier at night.

Then there is the historical side of this.  Through many failed attempts
it has been show that dumpers in the kernel are fragile beasts that work
up until you actually have a real world failure and then they let you
down.  Kexec on panic is better as it works 65% or so of the time,
and definitely won't corrupt your bits if it fails.  I don't see what
makes kmsg_dump better than all of the past failed and useless kernel
dumpers.

Eric

  reply	other threads:[~2010-09-27 16:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-16 20:16 [PATCH] Fix kexec abort due to IPI from panic() Seiji Aguchi
2010-09-16 23:13 ` Eric W. Biederman
2010-09-17 15:08   ` Seiji Aguchi
2010-09-24 13:08   ` [RFC][PATCH] " Seiji Aguchi
2010-09-27 16:59     ` Eric W. Biederman [this message]
2010-10-09  0:02       ` 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=m1eicfp1fz.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=David.Woodhouse@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=anton@samba.org \
    --cc=ben@decadent.org.uk \
    --cc=dle-develop@lists.sourceforge.net \
    --cc=jason.wessel@windriver.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=randy.dunlap@oracle.com \
    --cc=satoru.moriya@hds.com \
    --cc=seiji.aguchi@hds.com \
    --cc=simon.kagstrom@netinsight.net \
    --cc=xiyou.wangcong@gmail.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