Re: [PATCH v4 6/8] x86: bump ZO_z_extra_bytes margin for zstd

[Nick Terrell]

> On Apr 2, 2020, at 8:58 AM, Borislav Petkov <bp@xxxxxxxxx> wrote:
> 
> On Wed, Apr 01, 2020 at 05:33:03PM +0000, Nick Terrell wrote:
>> The code is currently written so that all the compression algorithms use the
>> same ZO_z_extra_bytes. It is taken to be the maximum of the growth rate
>> plus the maximum fixed overhead. Just a few lines above is the comment:
>> 
>> # â Hence safety
>> # margin should be updated to cover all decompressors so that we don't
>> # need to deal with each of them separately. Please check
>> # the description in lib/decompressor_xxx.c for specific information.
>> 
>> So I was been following the guidance in the comments.
> 
> Please state that in the commit message when you send your next
> revision.

Will do.

>> Does it matter? Iâm not an expert here,
> 
> Huh, you're only sending the code then? Or what do you mean with not
> being an expert?

I mean that while Iâve read and understood this piece of the code, have tested
the patches, have followed the template of other compression methods
added, and am confident in the correctness of the code, Iâm not a regular
contributor to the pre-boot x86 kernel code. So it is possible that there is a
use case for kernel compression that Iâm not aware of where RAM is extremely
tight and within 64 KB of the current limits.

It seems to me that adding 64KB to the memory requirement for kernel
decompression is not going to break anyone. If it did the kernel image is taking
up nearly all available RAM, which doesnât seem likely. But, I donât know all
use cases. If it does break someone, we can put up a separate patch that
switches all the compression methods over a per-method ZO_z_extra_bytes.

Best,
Nick