On Tue, 17 Dec 2024 09:46:30 -0800 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > Now you basically hide that, and make it harder to see any data from a > bad kernel (since you presumably need to boot into a good kernel to do > analysis). Note, this isn't for debugging kernels that crash at boot. There's other methods to debug things like that. Like, ftrace_dump_on_oops. This is for debugging something that happens after boot or in the field. Where the "bad" kernel can still boot in a good state. The kernel should be good enough to boot into a state where you can extract the trace and send it offline somewhere. I used this to debugging a few things in development, where someone hands me a reproducer. I enabled the boot_mapped buffer, run the reproducer, the system crashes and reboots into the same kernel. Then I was able to debug what happened, as long as I don't re-run the reproducer. But I did do several iterations of: Start boot mapped tracing, run reproducer, crash, reboot, look at boot mapped trace. Restart boot mapped tracing with more events, run reproducer, crash, reboot, look at mapped trace, wash, rinse, repeat. -- Steve
