On Fri, May 03, 2024 at 12:51:00PM -0700, Luis Chamberlain wrote: > Thanks for the cleanups, this is certainly now in the right direction. > Generic long term growth questions below. > > On Thu, May 02, 2024 at 11:56:03PM +0000, Allen Pais wrote: > > Why is this being done? > > We have observed that during a crash when there are more than 65k mmaps > > in memory, the existing fixed limit on the size of the ELF notes section > > becomes a bottleneck. The notes section quickly reaches its capacity, > > I'm not well versed here on how core dumps associate mmaps to ELF notes > section, can you elaborate? Does each new mmap potentially peg > information on ELF notes section? Where do we standardize on this? Does > it also change depending on any criteria of the mmap? This is all in fs/binfmt_elf.c, fill_note_info(). There's a dump for each thread's info, and then fill_files_note() (which is what this code is adjusting) which writes out every filename for any file-map VMAs. The format of NT_FILE record is documented above fill_files_note(). So, it all depends on the count of VMAs and length of filenames. > Depending on the above, we might want to be proactive to get a sense of > when we want to go beyond the new 16 MiB max cap on new mmaps for instance. > How many mmaps can we have anyway too? INT_MAX :) I'm fine with the new 16MiB max for the coredump. If we really need to go beyond this, we might need to avoid building the entire thing in memory, and instead move it all into write_note_info() directly, but I'm not interested in that refactor unless we have an overwhelmingly good reason to do so. -- Kees Cook
