On Wed, May 13, 2020 at 09:34:49AM +0200, Petr Mladek wrote: > On Tue 2020-05-12 11:45:54, Kees Cook wrote: > > Here are the problems I see being solved by this: > > > > - lifting kmsg dump reason filtering out of the individual pstore > > backends and making it part of the "infrastructure", so that > > there is a central place to set expectations. Right now there > > is a mix of explicit and implicit kmsg dump handling: > > > > - arch/powerpc/kernel/nvram_64.c has a hard-coded list > > It handles restart, halt, poweroff the same way. I wonder if anyone > would want to distinguish them. > > > - drivers/firmware/efi/efi-pstore.c doesn't expect anything but > > OOPS and PANIC. > > - drivers/mtd/mtdoops.c tries to filter using its own dump_oops > > and doesn't expect anything but OOPS and PANIC. > > - fs/pstore/ram.c: has a hard-coded list and uses its own > > dump_oops. > > - drivers/mtd/mtdpstore.c (under development[3]) expected only > > OOPS and PANIC and had its own dump_oops. > > The others handle only panic or oops. > > What about splitting the reason into two variables? One for severity > and other for shutdown behavior. I mean: > > + reason: panic, oops, emergency, shutdown (ordered by severity) > + handling: restart, halt, poweroff > > Or we might just replace KMSG_DUMP_RESTART, KMSG_DUMP_HALT, > KMSG_DUMP_POWEROFF with a single KMSG_DUMP_SHUTDOWN. > > Then the max reason variable would make sense. That would work for me, yeah. Pavel, is that enough granularity for you? -- Kees Cook
