This document discusses kernel panic and OOPS handling in Linux. It describes how panic and OOPS details are printed to the console and passed to registered notifiers. It also discusses pstore, which provides a filesystem interface to save and access panic and OOPS logs. Pstore implements a bridge pattern with backends like Ramoops that use RAM to store the logs. The document outlines challenges for writing new pstore backends and references additional resources.

1. Logging Kernel OOPS and
Panic
T.V.R.PRASAD

2. Panic handling in the kernel
• kernel/panic.c
• void panic(const char *fmt, ...)
• Pumps the panic details on the console
• __crash_kexec() to kexec to a kernel marked for crash handling (if it exists).
• atomic_notifier_call_chain(&panic_notifier_list, 0, buf) , runs through the panic
notifiers registered by various drivers with the buffer containing details of the
panic.
• kmsg_dump(KMSG_DUMP_PANIC) , notify the panic to kmsg_dumpers to start
reading the kmsg buffer.

3. OOPS handling in the kernel
• arch/arm/kernel/traps.c
• void die(const char *str, struct pt_regs *regs, int err)
• __die prints out the verbose output on the console and invokes the die notifier
chain.
• atomic_notifier_call_chain(&die_chain, val, &args) , kernel/notifier.c
• Individual notifer for OOPS can be registered using register_die_notifier() defined
in kernel/notifier.c
• kmsg_dump(KMSG_DUMP_OOPS) , notify the OOPS for kmsg_dumpers to start
reading the kmsg buffer.

4. What is pstore
• pstore is a pseudo filesystem
• pstore implements the bridge pattern , where pstore is the
abstraction and the “pstore backend” is the actual
implementation.
• Ramoops is an implementation of the pstore backend , where
RAM is the backend storage for storing the panic/OOPS
information.
• The backend for pstore can be implemented by implementing the
interface in the structure “struct pstore_info” defined in
include/linux/pstore.h

5. pstore contd …
• fs/pstore/platform.c ,contains the API for writing a pstore
backend.
• pstore_register , register a new kmsg_dumper using
kmsg_dump_register.
• pstore kmsg_dumper uses kmsg_dump_get_buffer() to get the
details of the panic/OOPS.
• Populates the last 8K of data into the buffer as
kmsg_dump_get_buffer reads from the end.

6. mtdoops and mmcoops
• Reference implementation of saving kernel OOPS to a mtd
device.
• Uses ksmg_dumper directly instead of pstore.
• drivers/mtd/mtdoops.c , has the implementation.
• mmcoops similar implementation , but not upstream.
• https://patchwork.kernel.org/patch/5897821/ reference patch for
mmcoops.

7. Challenges of writing a pstore backend
• Consider if the MMC driver crashes and MMC is the pstore
backend.
• Just to ensure the above is handled efficiently ,it is
recommended the function writing the panic/oops buffer to the
pstore backend not use interrupts or any kernel infrastructure.
• Use polling and do not use any scheduler infrastructure from
the kernel.

8. References
• https://stackoverflow.com/questions/18118807/linux-apanic-
mechanism-and-difference-from-newer-ram-console-persistent-
ram-mech
• https://android.googlesource.com/kernel/bcm/+/android-bcm-
tetra-3.10-kitkat-wear/drivers/misc/apanic_mmc.c
• http://linux-kernel.2935.n7.nabble.com/PATCH-v2-00-26-pstore-
mmc-add-mmc-as-backend-for-pstore-td550501i20.html
• ramoops.txt of the Linux kernel documentation.

9. Thank You