On Fri, Sep 30, 2022 at 03:31:17PM -0300, Guilherme G. Piccoli wrote: > On 30/09/2022 12:51, Ard Biesheuvel wrote: > > [...] > > > > 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) > > > > Thanks a lot Ard, this seems to be the fix! Tested with lz4/zstd/deflate > in both ramoops/efi backends, and all worked fine. It makes sense, > outlen was modified in the previous API and not in the acomp thing, so > it was a good catch =) > > > >> 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) > > Agreed - in fact seems it was reverted already. More than that, I found > yet another small issue in the acomp refactor, a memory leak - attached > is a patch with the fix, feel free to integrate in your acomp refactor > when re-submitting (I mean, feel free to just integrate the code, don't > need to send it as a separate patch/fix). > > I'm also working some fixes in implicit conversions in pstore that > aren't great (unsigned -> int in many places), I'll send some stuff next > week. Awesome! Thank you both! I'll probably be busy for the next week with the merge window, but after that I'll pull new stuff into -next for pstore. I appreciate more people poking around in the code. :) -- Kees Cook
