On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov anton.vorontsov@linaro.org wrote:
Having automatic updates seems pointless for production system, and even dangerous and thus counter-productive:
- If we can mount pstore, or read files, we can as well read
/proc/kmsg. So, there's little point in duplicating the functionality and present the same information but via another userland ABI;
- Expecting the kernel to behave sanely after oops/panic is naive.
It might work, but you'd rather not try it. Screwed up kernel can do rather bad things, like recursive faults[1]; and pstore rather provoking bad things to happen. It uses:
1. Timers (assumes sane interrupts state); 2. Workqueues and mutexes (assumes scheduler in a sane state); 3. kzalloc (a working slab allocator);
That's too much for a dead kernel, so the debugging facility itself might just make debugging harder, which is not what we want.
Maybe for non-oops message types it would make sense to re-enable automatic updates, but so far I don't see any use case for this. Even for tracing, it has its own run-time/normal ABI, so we're only interested in pstore upon next boot, to retrieve what has gone wrong with HW or SW.
So, let's disable the updates by default.
I'll let Tony ack this, but I'm fine with it -- making this configurable is sufficient for my needs. :)
diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c index 4f49bb4..1dbf49d 100644 --- a/fs/pstore/platform.c +++ b/fs/pstore/platform.c @@ -41,10 +41,11 @@ * whether the system is actually still running well enough * to let someone see the entry */ -static int pstore_update_ms = 60000; +static int pstore_update_ms = -1; module_param_named(update_ms, pstore_update_ms, int, 0600); MODULE_PARM_DESC(update_ms, "milliseconds before pstore updates its content "
- "(default is 60000; -1 means runtime updates are disabled)");
- "(default is -1, which means runtime updates are disabled; "
- "enabling this option is not safe)");
Perhaps "enabling this option may lead to further corruption on Oopses" or something more specific?
-Kees