On 5/16/23 23:55, Kees Cook wrote: > On Mon, May 08, 2023 at 09:21:00PM +0530, Mukesh Ojha wrote: >> 1. Device_coredump allocates some configurable contigous memory that can be >> controlled >> via CONFIG or bootargs and later registers for panic notifiers. >> 2. Notifier gets added. >> 3. Pstore adds device_coredump as its front-end via dumper registration >> similar >> to kmsg being dump today. >> 4. Successful registration of dumper. >> 5. A device driver(A-Z) can register their buffer to be dumped as part of >> panic. >> 6. buffer gets added to the dump list. >> 7. Panic occurs. >> 8. iterate over registered drivers and copy their dump list to its own >> memory and if >> it crosses device core dump memory log an error stop iterating. >> 9. Similar to devcore_dump() inline with kmsg_dump() >> 10.Copy the content to pstore region and this could be elf or raw binary >> that can be >> discussed. > > Yeah, I think having something like the panic dump handlers for > driver-specific data sounds like a fine idea (as long as we have actual > users of such an interface). > > I think it would be easy to add another front-end to pstore (via the > enums, etc), and expose it via a new template filename in the pstorefs. > Hello Kees, Currently I am working to get a similar design on Pstore as described by Mukesh, with some differences. I want to be able to register memory areas into Pstore, not by doing a copy, just by registering via a new API (as a frontend, area pointer and size). Further, these memory areas would be registered to a new type of zone inside pstore/zone called directly mapped zone, and then registered to any kind of backend that would support it. The backend would then decide what to do with the memory area, have it ready in a list for a panic case, hangup, or hardware fault; or something else. This implementation would avoid memory copy operations, memory reservations, and dependency to a panic handler being run. It would work in multiple scenarios, not just when the kernel is being able to run a panic handler. Further, the data can be extracted either by JTAG, firmware, remote processor or any other solution, including dedicated storage, shared memory. One could then use it to construct a coredump or specific dump information. Having different memory areas being registered has the advantage of being flexible and small, ranging from nothing to a full kernel memory range. What do you think about this approach ? Do you see it working like this ? Thank you for your suggestions, Eugen
