All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.