From: Anton Vorontsov <cbouatmailru@gmail.com>
To: Kees Cook <keescook@chromium.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
Arnd Bergmann <arnd@arndb.de>,
John Stultz <john.stultz@linaro.org>,
Shuah Khan <shuahkhan@gmail.com>,
arve@android.com, Rebecca Schultz Zavin <rebecca@android.com>,
Jesper Juhl <jj@chaosbits.net>,
Randy Dunlap <rdunlap@xenotime.net>,
Stephen Boyd <sboyd@codeaurora.org>,
Thomas Meyer <thomas@m3y3r.de>,
Andrew Morton <akpm@linux-foundation.org>,
Marco Stornelli <marco.stornelli@gmail.com>,
WANG Cong <xiyou.wangcong@gmail.com>,
linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org,
linaro-kernel@lists.linaro.org, patches@linaro.org,
kernel-team@android.com
Subject: Re: [PATCH 14/14] pstore/platform: Remove automatic updates
Date: Mon, 21 May 2012 21:54:07 -0700 [thread overview]
Message-ID: <20120522045406.GA24770@lizard> (raw)
In-Reply-To: <CAGXu5j+kE+cagPSjF5yGsxvuwxTaFY3t_BmiroJ+qCx2Fydstg@mail.gmail.com>
On Mon, May 21, 2012 at 12:59:59PM -0700, Kees Cook wrote:
[...]
> Hrm. This complicates testing a bit. I need more convincing. :)
>
> Systems run with panic_on_oops=0, and plenty of failure paths will
> just kill "current" instead of bringing the entire system down. I
> would much rather allow for the possibility to get oopses when they
> happen than to have to wait a full reboot cycle to "notice" them.
Well, as I use qemu/kvm for testing, rebooting is actually faster
than waiting for 60 seconds, so I didn't consider this use-case. :-)
But yes, I see the point: as pstore's debug function of itself,
updates might make sense.
So, you mentioning the panic_on_oops made me think of a kernel
command line option, this will also eliminate the 60 seconds hard-
coded interval.
But personally I'd still like it disabled by default, otherwise it
is possible pstore to screw things because of itself, and that
eliminates the point of having it as a reliable debug facility;
IMO, it should as much non-intrusive by default as possible, and
that's what we would want for production kernels anyway.
I'll replace this patch with another one that will add
pstore.update_ms kernel command line option.
Thanks!
--
Anton Vorontsov
Email: cbouatmailru@gmail.com
prev parent reply other threads:[~2012-05-22 4:55 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-18 22:23 [PATCH v3 0/14] Merge ram_console into pstore, and more Anton Vorontsov
2012-05-18 22:24 ` [PATCH 01/14] pstore/inode: Make pstore_fill_super() static Anton Vorontsov
2012-05-18 22:24 ` [PATCH 02/14] pstore/ram: Should update old dmesg buffer before reading Anton Vorontsov
2012-05-18 23:55 ` Colin Cross
2012-05-18 22:24 ` [PATCH 03/14] pstore/ram_core: Do not reset restored zone's position and size Anton Vorontsov
2012-05-18 23:42 ` Colin Cross
2012-05-22 13:19 ` Anton Vorontsov
2012-05-18 22:24 ` [PATCH 04/14] pstore/ram: Should zap persistent zone on unlink Anton Vorontsov
2012-05-18 23:52 ` Colin Cross
2012-05-18 22:25 ` [PATCH 05/14] pstore: Add console log messages support Anton Vorontsov
2012-05-18 22:25 ` [PATCH 06/14] pstore/ram: Introduce ramoops_context.max_dump_count Anton Vorontsov
2012-05-18 22:25 ` [PATCH 07/14] pstore/ram: Factor dmesg przs initialization out of probe() Anton Vorontsov
2012-05-18 22:25 ` [PATCH 08/14] pstore/ram: Factor ramoops_get_dump_prz() out of ramoops_pstore_read() Anton Vorontsov
2012-05-18 22:25 ` [PATCH 09/14] pstore/ram: Add console messages handling Anton Vorontsov
2012-05-18 22:25 ` [PATCH 10/14] pstore/ram_core: Silence some printks Anton Vorontsov
2012-05-18 22:26 ` [PATCH 11/14] pstore/ram: Add some more documentation and examples Anton Vorontsov
2012-05-18 22:26 ` [PATCH 12/14] staging/android: Remove ram_console driver Anton Vorontsov
2012-05-18 22:26 ` [PATCH 13/14] pstore/ram_core: Remove now unused code Anton Vorontsov
2012-05-18 22:26 ` [PATCH 14/14] pstore/platform: Remove automatic updates Anton Vorontsov
2012-05-21 19:59 ` Kees Cook
2012-05-22 4:54 ` Anton Vorontsov [this message]
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=20120522045406.GA24770@lizard \
--to=cbouatmailru@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=arve@android.com \
--cc=ccross@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jj@chaosbits.net \
--cc=john.stultz@linaro.org \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=linaro-kernel@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marco.stornelli@gmail.com \
--cc=patches@linaro.org \
--cc=rdunlap@xenotime.net \
--cc=rebecca@android.com \
--cc=sboyd@codeaurora.org \
--cc=shuahkhan@gmail.com \
--cc=thomas@m3y3r.de \
--cc=tony.luck@intel.com \
--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