On Fri, May 18, 2012 at 3:26 PM, Anton Vorontsov <anton.vorontsov@xxxxxxxxxx> wrote: > Having automatic updates seems pointless, 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. > > So, let's remove the automatic updates, this keeps things simple > and safe. > > (Maybe for non-oops message types it would make sense to add > 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.) 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. -Kees -- Kees Cook Chrome OS Security _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
