Re: [RFC PATCH 0/6] initramfs: reduce buffer footprint

[David Disseldorp <ddiss@suse.de>]

On Wed, 16 Oct 2024 00:34:15 +0100, Al Viro wrote:

> On Tue, Oct 15, 2024 at 01:11:57PM +0000, David Disseldorp wrote:
> > There are a number of stack, heap and data-segment buffers which are
> > unnecessary for initramfs unpacking. This patchset attempts to remove
> > them by:
> > - parsing cpio hex strings in place, instead of copying them for
> >   nul-termination. (Patches 1 & 2).
> > - reusing a single heap buffer for cpio header, file and symlink paths,
> >   instead of three separate buffers. (Patches 3 & 4).
> > - reusing the heap-allocated cpio buffer across both builtin and
> >   bootloader-provided unpack attempts. (Patch 5).
> > - reusing the heap-allocated cpio buffer for error messages on
> >   FSM-exit, instead of a data-segment buffer. (Patch 6).
> > 
> > I've flagged this as an RFC as I'd like to improve the commit messages
> > and also provide more thorough testing, likely via kunit / kselftest
> > integration.  
> 
> Umm...  An obvious question: what's the point?  Reducing the amount of
> temporary allocations (and not particularly large ones, at that) done
> during early boot and freed before we run anything in user mode?

"reduce buffer footprint" is a bad title... My initial motivation was to
improve initramfs unpack error reporting (still WIP), following a
downstream bug report.
Patches 1 & 2 avoid 13 memcpy() calls for every initramfs entry and IMO
leave the code more readable, so should be justified once I have
profiling data.
Patches 3-5 remove five extra kmalloc() calls when booting with built-in
and bootloader initramfses. I doubt it'll be visible in profiling, but
they allow for buffer reuse for dynamic error messages instead of
sprinkling data-segment buffers around, like the one removed in patch 6.