From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: Tony Luck <tony.luck@intel.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Michal Clapinski <mclapinski@google.com>,
Kees Cook <kees@kernel.org>,
kexec@lists.infradead.org, linux-kernel@vger.kernel.org,
Alexander Graf <graf@amazon.com>,
Pratyush Yadav <pratyush@kernel.org>
Subject: Re: [PATCH v2] pstore: add a KHO backend
Date: Fri, 12 Jun 2026 17:21:20 +0000 [thread overview]
Message-ID: <aiwbUfeaF9RdCGR-@plex> (raw)
In-Reply-To: <aiwa4jIWEMsvfnVg@kernel.org>
On 06-12 17:42, Mike Rapoport wrote:
> Hi,
>
> On Fri, Jun 05, 2026 at 02:10:40PM +0200, Michal Clapinski wrote:
> > Up to this point to preserve late shutdown logs in memory, users had to
> > predefine a memory region using ramoops. This commit changes this by
> > preserving a buffer using kexec-handover.
> >
> > pstore_kho supports preserving only 1 dmesg buffer.
> > It gets replaced with the new buffer on every kexec, so the user has to
> > copy the file out of pstore after every kexec.
> > There is no erase() support.
>
> Sorry I didn't jump at v1.
>
> pstore does not really need a KHO backend. It can use ram backend with
> reserve_mem and reserve_mem can be preserved with KHO already.
I just tested it, and it works well, I think it would be fine for
Google's requirements:
CONFIG_PSTORE=y
CONFIG_PSTORE_RAM=y
CONFIG_PSTORE_CONSOLE=y
With the following parameters:
'reserve_mem=2M:2M:dmesg_buffer ramoops.mem_name=dmesg_buffer ramoops.max_reason=5 ramoops.console_size=2097152 ramoops.record_size=0 ramoops.ftrace_size=0 ramoops.pmsg_size=0'
KHO preserves pstore properly. However, we need one patch that would
allow for ramoops console to capture the output even when quiet is
provided.
Pasha
WARNING: multiple messages have this Message-ID (diff)
From: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: Michal Clapinski <mclapinski@google.com>,
Kees Cook <kees@kernel.org>, Tony Luck <tony.luck@intel.com>,
"Guilherme G. Piccoli" <gpiccoli@igalia.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Alexander Graf <graf@amazon.com>,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org
Subject: Re: [PATCH v2] pstore: add a KHO backend
Date: Fri, 12 Jun 2026 17:21:20 +0000 [thread overview]
Message-ID: <aiwbUfeaF9RdCGR-@plex> (raw)
In-Reply-To: <aiwa4jIWEMsvfnVg@kernel.org>
On 06-12 17:42, Mike Rapoport wrote:
> Hi,
>
> On Fri, Jun 05, 2026 at 02:10:40PM +0200, Michal Clapinski wrote:
> > Up to this point to preserve late shutdown logs in memory, users had to
> > predefine a memory region using ramoops. This commit changes this by
> > preserving a buffer using kexec-handover.
> >
> > pstore_kho supports preserving only 1 dmesg buffer.
> > It gets replaced with the new buffer on every kexec, so the user has to
> > copy the file out of pstore after every kexec.
> > There is no erase() support.
>
> Sorry I didn't jump at v1.
>
> pstore does not really need a KHO backend. It can use ram backend with
> reserve_mem and reserve_mem can be preserved with KHO already.
I just tested it, and it works well, I think it would be fine for
Google's requirements:
CONFIG_PSTORE=y
CONFIG_PSTORE_RAM=y
CONFIG_PSTORE_CONSOLE=y
With the following parameters:
'reserve_mem=2M:2M:dmesg_buffer ramoops.mem_name=dmesg_buffer ramoops.max_reason=5 ramoops.console_size=2097152 ramoops.record_size=0 ramoops.ftrace_size=0 ramoops.pmsg_size=0'
KHO preserves pstore properly. However, we need one patch that would
allow for ramoops console to capture the output even when quiet is
provided.
Pasha
next prev parent reply other threads:[~2026-06-12 17:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 12:10 [PATCH v2] pstore: add a KHO backend Michal Clapinski
2026-06-10 20:34 ` Kees Cook
2026-06-10 20:34 ` Kees Cook
2026-06-11 9:18 ` Pratyush Yadav
2026-06-11 9:18 ` Pratyush Yadav
2026-06-11 18:55 ` Pasha Tatashin
2026-06-11 18:55 ` Pasha Tatashin
2026-06-12 14:42 ` Mike Rapoport
2026-06-12 14:42 ` Mike Rapoport
2026-06-12 17:21 ` Pasha Tatashin [this message]
2026-06-12 17:21 ` Pasha Tatashin
2026-06-12 17:57 ` Michał Cłapiński
2026-06-12 17:57 ` Michał Cłapiński
2026-06-12 18:38 ` Pasha Tatashin
2026-06-12 18:38 ` Pasha Tatashin
2026-06-12 18:49 ` Michał Cłapiński
2026-06-12 18:49 ` Michał Cłapiński
2026-06-12 18:51 ` Pasha Tatashin
2026-06-12 18:51 ` Pasha Tatashin
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=aiwbUfeaF9RdCGR-@plex \
--to=pasha.tatashin@soleen.com \
--cc=graf@amazon.com \
--cc=kees@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mclapinski@google.com \
--cc=pratyush@kernel.org \
--cc=rppt@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.