Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20220929215515.276486-1-gpiccoli@igalia.com> <202209291951.134BE2409@keescook>
 <56d85c70-80f6-aa73-ab10-20474244c7d7@igalia.com>
In-Reply-To: <56d85c70-80f6-aa73-ab10-20474244c7d7@igalia.com>
From:   Ard Biesheuvel <ardb@kernel.org>
Date:   Fri, 30 Sep 2022 17:51:38 +0200
Message-ID: <CAMj1kXFnoqj+cn-0dT8fg0kgLvVx+Q2Ex-4CUjSnA9yRprmC-w@mail.gmail.com>
Subject: Re: [REGRESSION][PATCH] Revert "pstore: migrate to crypto acomp interface"
To:     "Guilherme G. Piccoli" <gpiccoli@igalia.com>
Cc:     Kees Cook <keescook@chromium.org>, 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>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Fri, 30 Sept 2022 at 14:39, Guilherme G. Piccoli <gpiccoli@igalia.com> wrote:
>
> 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.
>

Does this help?

diff --git a/fs/pstore/platform.c b/fs/pstore/platform.c
index b2fd3c20e7c2..c0b609d7d04e 100644
--- a/fs/pstore/platform.c
+++ b/fs/pstore/platform.c
@@ -292,7 +292,7 @@ static int pstore_compress(const void *in, void *out,
                return ret;
        }

-       return outlen;
+       return creq->dlen;
 }

 static void allocate_buf_for_compression(void)


>
> > [...]
> > 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?
>

Makes sense

>
> >
> > 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.

Yeah better to revert - this was not a critical change anyway. But I
think the tweak above should fix things (it works for me here)