lkml.org 
[lkml]   [2021]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/2] x86/setup: consolidate early memory reservations
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@linux.ibm.com>
> >
> > 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.

\
 
 \ /
  Last update: 2021-01-25 16:41    [W:0.210 / U:0.060 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site