Messages in this thread | | | Date | Tue, 18 Oct 2011 11:10:58 -0400 | From | Don Zickus <> | Subject | Re: [RFC][PATCH -next] make pstore/kmsg_dump run after stopping other cpus in panic path |
| |
On Tue, Oct 18, 2011 at 10:52:22AM -0400, Seiji Aguchi wrote: > Hi, > > >> afacit this assumes that (reason == KMSG_DUMP_PANIC) if in_nmi(). Is > >> that always the case, and will it always be the case in the future? > > > > Currently, when kernel is in nmi context and kmsg_dump() are called, its reason is always "KMSG_DUMP_PANIC". > > > > >Perhaps a 'BUG_ON(in_nmi() && reason != KMSG_DUMP_PANIC)'? > > I don't think BUG_ON() is needed. > > If someone would like to log messages in the case of "in_nmi() && reason != KMSG_DUMP_PANIC", > he/she will add a new trigger as follows.
The point I was trying to make with the BUG_ON is to catch future uses of NMI and kmsg_dump that were implemented without understanding the restriction we place (you have to be in a panic path for NMI to use pstore/kmsg_dump).
That is part of the wider problem with kmsg_dump that Vivek talks about with me, is that it is just a giant hook in the panic path with limited auditing. So we need to explicit set our expectations with BUG_ONs/WARNs otherwise we might get bit later by them.
Cheers, Don
| |