> 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
