linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Guilherme G. Piccoli" <gpiccoli@igalia.com>
To: Kees Cook <keescook@chromium.org>, Ard Biesheuvel <ardb@kernel.org>
Cc: linux-kernel@vger.kernel.org, regressions@lists.linux.dev,
	linux-fsdevel@vger.kernel.org, kernel-dev@igalia.com,
	kernel@gpiccoli.net, Anton Vorontsov <anton@enomsg.org>,
	Colin Cross <ccross@android.com>, Tony Luck <tony.luck@intel.com>,
	Thorsten Leemhuis <linux@leemhuis.info>
Subject: Re: [REGRESSION][PATCH] Revert "pstore: migrate to crypto acomp interface"
Date: Fri, 30 Sep 2022 09:39:10 -0300	[thread overview]
Message-ID: <56d85c70-80f6-aa73-ab10-20474244c7d7@igalia.com> (raw)
In-Reply-To: <202209291951.134BE2409@keescook>

On 30/09/2022 00:29, Kees Cook wrote:
> [...]
> 
> Hi!
> 
> Thanks for looking at this. I wasn't able to reproduce the problem,
> initially. Booting with pstore.backend=ramoops pstore.compress=zstd and
> writing to /dev/pmsg0, after a reboot I'm able to read it back.
> 

Hi Kees, thanks a lot for your attention!
IIUC, compression applies to dmesg only, correct?


> [...] 
> What's your setup for this? I'm using emulated NVDIMM through qemu for
> a ramoops backend. But trying this with the EFI backend (booting
> undef EFI with pstore.backend=efi), I _do_ see the problem. That's
> weird... I suspect there's some back interaction with buffer size
> differences between ramoops and EFI & deflate and zstd.
> 
> And I can confirm EFI+zstd with the acomp change reverted fixes it.
> 

I'm using qemu but was able to use real HW (Steam Deck). In both cases,
kernel is not using the entire RAM ("mem=" parameter, for example) so we
can use a bit for ramoops. Also, both setups are UEFI, hence I can also
use efi_pstore.


> [...] 
> Hm, it's possible this was just sent directly to me? If that's true, I
> apologize for not re-posting it to lkml. I suspect I didn't notice at
> the time that it wasn't CCed to a list.

No need for apologies, thanks for the clarification! How about if we add
a mailing list in the pstore entry on MAINTAINERS file, since it's just
composed for you and 3 other people now? I mean, "officially" speaking,
it should be enough to send a patch for the 4 maintainers with no list
in CC, and that's bad for achieving purposes. What list should be the
best, fsdevel? Lkml?


> 
> No worries! Whatever the case, there's always -stable updates. :)

Heheh you're right! But for something like this (pstore/dmesg
compression broke for the most backends), I'd be glad if we could fix it
before the release.
Cheers,


Guilherme

  reply	other threads:[~2022-09-30 12:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-29 21:55 [REGRESSION][PATCH] Revert "pstore: migrate to crypto acomp interface" Guilherme G. Piccoli
2022-09-30  3:29 ` Kees Cook
2022-09-30 12:39   ` Guilherme G. Piccoli [this message]
2022-09-30 15:51     ` Ard Biesheuvel
2022-09-30 18:31       ` Guilherme G. Piccoli
2022-09-30 19:08         ` Kees Cook
2022-09-30 12:03 ` [REGRESSION][PATCH] Revert "pstore: migrate to crypto acomp interface" #forregzbot Thorsten Leemhuis

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=56d85c70-80f6-aa73-ab10-20474244c7d7@igalia.com \
    --to=gpiccoli@igalia.com \
    --cc=anton@enomsg.org \
    --cc=ardb@kernel.org \
    --cc=ccross@android.com \
    --cc=keescook@chromium.org \
    --cc=kernel-dev@igalia.com \
    --cc=kernel@gpiccoli.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@leemhuis.info \
    --cc=regressions@lists.linux.dev \
    --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;
as well as URLs for NNTP newsgroup(s).