On Mon, Jan 25, 2021 at 03:50:41PM +0100, Borislav Petkov wrote: > On Fri, Jan 15, 2021 at 10:32:54AM +0200, Mike Rapoport wrote: > > From: Mike Rapoport <rppt@xxxxxxxxxxxxx> > > > > The early reservations of memory areas used by the firmware, bootloader, > > kernel text and data are spread over setup_arch(). Moreover, some of them > > happen *after* memblock allocations, e.g trim_platform_memory_ranges() and > > trim_low_memory_range() are called after reserve_real_mode() that allocates > > memory. > > > > We did not observe corruption of these memory regions because memblock > > Make that "We" impersonal, passive voice pls. Ok. > > always allocates memory either from the end of memory (in top-down mode) or > > above the kernel image (in bottom-up mode). However, the bottom up mode is > > going to be updated to span the entire memory [1] to avoid limitations > > caused by KASLR. > > > > Consolidate early memory reservations in a dedicated function to improve > > robustness against future changes. Having the early reservations in one > > place also makes it clearer what memory must be reserved before we allow > > memblock allocations. > > Would it make sense to have a check with a WARN or so to catch early > reservations which get added after memblock allocations have been > allowed? To catch people who don't pay attention... This would make sense but it's tricky. From memblock perspective, allocations are always allowed and it is the user responsibility to ensure all the early reservations are done before allocating memory. So adding such a WARN would require a new memblock API and it's adoption by all architectures, which is way beyond the scope of this series :) -- Sincerely yours, Mike.
