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.
