From: Andrew Morton <akpm@linux-foundation.org>
To: Matthew Garrett <mjg@redhat.com>
Cc: linux-kernel@vger.kernel.org, dzickus@redhat.com,
vgoyal@redhat.com, seiji.aguchi@hds.com
Subject: Re: [PATCH V3] kmsg_dump: Don't run on non-error paths by default
Date: Tue, 14 Feb 2012 13:05:22 -0800 [thread overview]
Message-ID: <20120214130522.fdb05b81.akpm@linux-foundation.org> (raw)
In-Reply-To: <1328888715-21589-1-git-send-email-mjg@redhat.com>
On Fri, 10 Feb 2012 10:45:15 -0500
Matthew Garrett <mjg@redhat.com> wrote:
> Since 04c6862c055fb687c90d9652f32c11a063df15cf kmsg_dump() gets run on
> normal paths including poweroff and reboot. This is less than ideal given
> pstore implementations that can only represent single backtraces, since a
> reboot may overwrite a stored oops before it's been picked up by userspace.
> In addition, some pstore backends may have low performance and provide a
> significant delay in reboot as a result.
>
> This patch adds a printk.always_kmsg_dump kernel parameter (which can also
> be changed from userspace). Without it, the code will only be run on
> failure paths rather than on normal paths. The option can be enabled in
> environments where there's a desire to attempt to audit whether or not
> a reboot was cleanly requested or not.
So if I'm understanding it correctly, this patch reverts the kernel
behaviour to what it was before 04c6862c055fb687c9 ("kmsg_dump: add
kmsg_dump() calls to the reboot, halt, poweroff and emergency_restart
paths"). The user must now set printk.always_kmsg_dump to get the
04c6862c055fb687c9 behaviour.
Correct? If so, we should get this into 3.3 so we don't have a oddball
behaviour in one particular kernel release.
next prev parent reply other threads:[~2012-02-14 21:05 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 15:45 [PATCH V3] kmsg_dump: Don't run on non-error paths by default Matthew Garrett
2012-02-14 19:23 ` Matthew Garrett
2012-02-14 21:05 ` Andrew Morton [this message]
2012-02-14 21:12 ` Matthew Garrett
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=20120214130522.fdb05b81.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=dzickus@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mjg@redhat.com \
--cc=seiji.aguchi@hds.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.