From: Kees Cook <keescook@chromium.org>
To: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: gregkh@linuxfoundation.org, tony.luck@intel.com,
gpiccoli@igalia.com, johannes@sipsolutions.net,
rafael@kernel.org, linux-hardening@vger.kernel.org,
linux-kernel@vger.kernel.org, quic_shashim@quicinc.com,
quic_pkondeti@quicinc.com
Subject: Re: RFC design of device coredump collection on panic in Pstore
Date: Tue, 16 May 2023 13:55:21 -0700 [thread overview]
Message-ID: <202305161353.0F771E0@keescook> (raw)
In-Reply-To: <1683561060-2197-1-git-send-email-quic_mojha@quicinc.com>
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.
--
Kees Cook
next prev parent reply other threads:[~2023-05-16 20:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-08 15:51 RFC design of device coredump collection on panic in Pstore Mukesh Ojha
2023-05-15 6:52 ` Pavan Kondeti
2023-05-16 20:55 ` Kees Cook [this message]
2025-01-21 13:12 ` Eugen Hristev
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202305161353.0F771E0@keescook \
--to=keescook@chromium.org \
--cc=gpiccoli@igalia.com \
--cc=gregkh@linuxfoundation.org \
--cc=johannes@sipsolutions.net \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_mojha@quicinc.com \
--cc=quic_pkondeti@quicinc.com \
--cc=quic_shashim@quicinc.com \
--cc=rafael@kernel.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.