Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 25 Jan 2021 17:31:14 +0200
From:   Mike Rapoport <rppt@kernel.org>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Andrea Arcangeli <aarcange@redhat.com>,
        Baoquan He <bhe@redhat.com>,
        David Hildenbrand <david@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@redhat.com>,
        Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>,
        Mike Rapoport <rppt@linux.ibm.com>, Qian Cai <cai@lca.pw>,
        Thomas Gleixner <tglx@linutronix.de>,
        Vlastimil Babka <vbabka@suse.cz>, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, x86@kernel.org
Subject: Re: [PATCH 1/2] x86/setup: consolidate early memory reservations
Message-ID: <20210125153114.GH6332@kernel.org>
References: <20210115083255.12744-1-rppt@kernel.org>
 <20210115083255.12744-2-rppt@kernel.org>
 <20210125145041.GD23070@zn.tnic>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210125145041.GD23070@zn.tnic>
Precedence: bulk

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.