On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov <anton.vorontsov@xxxxxxxxxx> wrote: > Having automatic updates seems pointless for production system, and > even dangerous and thus counter-productive: > > 1. 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; > > 2. 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 -- Kees Cook Chrome OS Security _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
