public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Kees Cook <keescook@chromium.org>
To: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Mukesh Ojha <quic_mojha@quicinc.com>,
	Elliot Berman <quic_eberman@quicinc.com>,
	Kees Cook <kees@kernel.org>,
	Isaac Manjarres <isaacmanjarres@google.com>,
	John Stultz <jstultz@google.com>, Tony Luck <tony.luck@intel.com>,
	"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
	kernel-team@android.com, linux-hardening@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	Trilok Soni <quic_tsoni@quicinc.com>,
	Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
Subject: Re: [PATCH] pstore/ram: Add support for dynamically allocated ramoops memory regions
Date: Wed, 5 Jul 2023 15:21:04 -0700	[thread overview]
Message-ID: <202307051516.AE6080BF@keescook> (raw)
In-Reply-To: <bd531778-a587-e4d0-e360-432208f064ea@kernel.org>

On Tue, Jul 04, 2023 at 08:07:09AM +0200, Krzysztof Kozlowski wrote:
> On 26/06/2023 19:34, Mukesh Ojha wrote:
> > I have tried multiple attempt already to get this patch in
> > 
> > https://lore.kernel.org/lkml/1675330081-15029-2-git-send-email-quic_mojha@quicinc.com/
> > 
> > later tried the approach of patch #9 along with minidump series..
> 
> For all dynamic reserved-memory-ramoops thingy, I think Rob made clear
> statement:
> 
> "I don't think dynamic ramoops location should be defined in DT."
> 
> https://lore.kernel.org/lkml/CAL_JsqKV6EEpsDNdj1BTN6nODb=hsHkzsdkCzzWwnTrygn0K-A@mail.gmail.com/
> 
> Please do not send three versions of the same patch hoping one will
> sneak in.

If I understand correctly, the driving issue here is that minidump wants
to be able to find the crash report "externally". Perhaps pstore could
provide either a known symbol that contains the address that was used,
or could add something to the kernel crash image (like is done for
KASLR), so that an external consumer of the kernel crash image could
find it?

And then the RAM backend for pstore could gain an option for "just
allocate regular RAM" for holding the dump? In other words, the address
is chosen by pstore, but an external consumer could still locate it.

-Kees

-- 
Kees Cook

  reply	other threads:[~2023-07-05 22:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-22  0:52 [PATCH] pstore/ram: Add support for dynamically allocated ramoops memory regions Isaac J. Manjarres
2023-06-22  4:47 ` John Stultz
2023-06-22  5:15   ` Kees Cook
2023-06-22 17:26     ` Isaac Manjarres
2023-06-22 17:58       ` Kees Cook
2023-06-22 19:51         ` Elliot Berman
2023-06-26 17:34           ` Mukesh Ojha
2023-07-04  6:07             ` Krzysztof Kozlowski
2023-07-05 22:21               ` Kees Cook [this message]
2023-07-06 16:00                 ` Mukesh Ojha
2023-07-04  6:05           ` Krzysztof Kozlowski
2023-06-22 17:19   ` Isaac Manjarres
2023-07-04  6:05 ` Krzysztof Kozlowski

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=202307051516.AE6080BF@keescook \
    --to=keescook@chromium.org \
    --cc=gpiccoli@igalia.com \
    --cc=isaacmanjarres@google.com \
    --cc=jstultz@google.com \
    --cc=kees@kernel.org \
    --cc=kernel-team@android.com \
    --cc=krzk@kernel.org \
    --cc=linux-hardening@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_eberman@quicinc.com \
    --cc=quic_mojha@quicinc.com \
    --cc=quic_satyap@quicinc.com \
    --cc=quic_tsoni@quicinc.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox