From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2F37DC433DB for ; Mon, 25 Jan 2021 15:31:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9CF0723B74 for ; Mon, 25 Jan 2021 15:31:25 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9CF0723B74 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E35758D0003; Mon, 25 Jan 2021 10:31:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DBE108D0001; Mon, 25 Jan 2021 10:31:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C85C98D0003; Mon, 25 Jan 2021 10:31:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0116.hostedemail.com [216.40.44.116]) by kanga.kvack.org (Postfix) with ESMTP id AFD268D0001 for ; Mon, 25 Jan 2021 10:31:24 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6614E181AC9CC for ; Mon, 25 Jan 2021 15:31:24 +0000 (UTC) X-FDA: 77744686488.08.base80_4b08f6a27586 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 2EBCA1819E793 for ; Mon, 25 Jan 2021 15:31:24 +0000 (UTC) X-HE-Tag: base80_4b08f6a27586 X-Filterd-Recvd-Size: 3641 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Mon, 25 Jan 2021 15:31:23 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 9DC8423B70; Mon, 25 Jan 2021 15:31:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611588682; bh=qjqOOxZHKUNkJrWJLLIv5ELWV/kMvv5CYzw1+xODwS0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jAIjljpRC9HZtZNqGk1TAWWiZm0+mJJBd9Cqz1brf/HrRlTH3LnsgjuoyIlO0NH2K tAL2IGsS6H92+0RRFMP59nK7k6ZzMd8lCdCYrRMdFLAE+9tOUopdi9P9kTQY3fw16M l0pQ9luW5RcK21IceGedE4jzyKw6624rhQaJq7uqe4miZ1PFToGe0PaYqCXjoJamwW F3j+zMU4FJM796dn28MGcq81vHzqF3a0zEN/T3eAeHDdYB9FRdtsQAjrh7YzysuA9n APsvKnhcdqxxG6d/q9lPg8myw7RX5B3BJKCik7ZRG4meBfCABC9vc/wqRlIrbl3nbv qH+4ravqCopLA== Date: Mon, 25 Jan 2021 17:31:14 +0200 From: Mike Rapoport To: Borislav Petkov Cc: Andrew Morton , Andrea Arcangeli , Baoquan He , David Hildenbrand , "H. Peter Anvin" , Ingo Molnar , Mel Gorman , Michal Hocko , Mike Rapoport , Qian Cai , Thomas Gleixner , Vlastimil Babka , 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> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 > > > > 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.