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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D926CC46467 for ; Wed, 4 Jan 2023 19:35:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7BE0A8E0002; Wed, 4 Jan 2023 14:35:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 76D4C8E0001; Wed, 4 Jan 2023 14:35:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 636D18E0002; Wed, 4 Jan 2023 14:35:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 542088E0001 for ; Wed, 4 Jan 2023 14:35:18 -0500 (EST) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 17ED3406BD for ; Wed, 4 Jan 2023 19:35:18 +0000 (UTC) X-FDA: 80318120316.09.668D6E1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id 6CB5E100007 for ; Wed, 4 Jan 2023 19:35:16 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CZG94dIa; spf=pass (imf05.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672860916; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=vxL5P38A5MF2VaxMGG+r7VO721m/rv62JfmYkR/SGps=; b=ua2OI8C7FfOlSDJTyoOHXXCjd6aRViLukJN9URkQXLpTBO0XSZ0P952Ssmtq2tIQv/2sld EDXVGFPFB5q7GsHoOFd4HMy4D4ej/+Cf2LhCHK7KIWsq/pTriSAvmlRW1k7z3SgyM1V7lf YiaL3rAeIrNFbDdYDf1VH9o48bK1Fq0= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CZG94dIa; spf=pass (imf05.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672860916; a=rsa-sha256; cv=none; b=prOKP7nbydj62miNYkFRO2wN9PDz9fWi3c1u9wydZKiiJNiwi1uWFRk6QnrX5xPvgRJTa8 5LCaGXrvxfHuQhOzf4uw8IdEJWzMT1Zuo0+nt/qaaq9XxynpMzcJOTm+R94ibTq5AUNfIA WTz76CfHMgUI/P2bntu+TfsjSRoloQI= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4C38A617ED; Wed, 4 Jan 2023 19:35:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E819FC433EF; Wed, 4 Jan 2023 19:35:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1672860914; bh=nBtzaERYqz1fl0bdAO7NgdUE0uQtmK9u3n6Av8noF4A=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=CZG94dIaCb9RFeCz/iBmZN53uq60BtSkPGf5lymH1RW37BYp5I/uIK7xaqHuPZzxk jqwDrxZN4LxxDwMTFq0fQuAdNnS3A7jk9hqsyIYl+toChVSOKl9kNqgG2THRIBqHl+ 7eOgSoGzizy8hjdYhfsuwxh0dUYV6jO0U7eOnl3rxWtoP4Dc4EsRW5UPs81KWBboul cfpyt/XnCV8OVbITcL7jpUfTfiB+olHJhQSuGzux3M4zWY6EmQjnxnWpnK7pk7SPl7 K3ATjvbPmUv6A8vmO9hh6oGOeMGokKEvcPSbruIdgZPrODecyW31L8B+g4PsAnzqmC BUP7gcwQQzufA== Date: Wed, 4 Jan 2023 21:34:57 +0200 From: Mike Rapoport To: Aaron Thompson Cc: linux-mm@kvack.org, "H. Peter Anvin" , Alexander Potapenko , Andrew Morton , Andy Shevchenko , Ard Biesheuvel , Borislav Petkov , Darren Hart , Dave Hansen , Dmitry Vyukov , Ingo Molnar , Marco Elver , Thomas Gleixner , kasan-dev@googlegroups.com, linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, platform-driver-x86@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 1/1] mm: Always release pages to the buddy allocator in memblock_free_late(). Message-ID: References: <20230104074215.2621-1-dev@aaront.org> <010101857bbc4d26-d9683bb4-c4f0-465b-aea6-5314dbf0aa01-000000@us-west-2.amazonses.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010101857bbc4d26-d9683bb4-c4f0-465b-aea6-5314dbf0aa01-000000@us-west-2.amazonses.com> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6CB5E100007 X-Rspam-User: X-Stat-Signature: rqkm84kewxczd3ryo1prqyeb8canp5ds X-HE-Tag: 1672860916-538421 X-HE-Meta: U2FsdGVkX18EkzbXX32zJg8X+zK95m/Mmd7FHSHM1dUt2RyQFW/y5XT3PktDQhTfXzAKtbwfkWxpTTZwwBcL3wZj4aSLJLCCAbZoxCou5CB1bUpS8KSbVLdfyzKHriSddSzni7JzgX0WIpb1e8XdcOQS+H/Sr4CCpvEVCJNWbe7Yt6wDft0ekeUpqSD4kRSIw4+HLkzzH/TzlvMs3KMpDapLtNLtLk9UFqJcntMKsqpEyEa69Xxgugv/gmE7zO2/iy2OBpU6a6xhLzJw6++xm2d+79xjcIGfJDH4scgCRAjFmhneMbDSI57J0naG4Lj+af91Y6IS4uNvN8IyAqPABrl3S9uHmkbXSva0+iuhr4F3/lVVlsaJzzcP4S1cbvA1FnYrw5oyczuu9lyUN573mOK47Zaeg2/5Cu7j7yu74ZQVA3XT1bUP9c5umzEA3vDoSbxcAPHsTesEvKbJT7GWFt40pmAGvOBl7lT4g7uQcyw6ixsuxJ4PVwYKYXkhcw/rE5sCQRYDVY9sDSW0vNR1HCuAxlW2w1uyMpUBBZzblc15og3pKTx4m2wqN2b2Zut8z2VZMQZzWYS1uJbD3J+laDJoYvOlFkC4xv/yX8DKWeY6G14iS4FhQLzXqmXxcuq5e3c86MuLLRt82t0OU/7CUmwfU+PoDUzyHp9WDGE1nGso4YyNmaQ3ogICb52yAYy+TI5bDOd6VuX0ng0LhPiEW3LCuF5XUoR8BmJOFI9Z+XKi0hdIqaecIENXT+LteGmkqhWJryD5TjB/pkKagg8399AY08uilIf8zrFOAljajVnXFJ4JLpO3iPacHYHDulHqjq6zNVQ7jXx70kenTR+Il+m3Fsn2TyV51heyI/ULvpP9Hb2zMkN6Xkqq2WWP/16FrVzGooDyhLwoUSoqvYqVkkTDXoSEYb3KHCJhka2MdrDkQTRuxfm/znMTGfJfPjxHRW3tm/95nzDKznbDgJn KeN0V+T8 1LAHdNxDy2vMqIZXnnrS13U+ZnzL+jE3lY83saszr9ICMfCwq58N45ERkK1x9rcFsfHZS6W/VzPnbCn30rYZdlDHmGQ== 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: Hi, On Wed, Jan 04, 2023 at 07:43:36AM +0000, Aaron Thompson wrote: > If CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled, memblock_free_pages() > only releases pages to the buddy allocator if they are not in the > deferred range. This is correct for free pages (as defined by > for_each_free_mem_pfn_range_in_zone()) because free pages in the > deferred range will be initialized and released as part of the deferred > init process. memblock_free_pages() is called by memblock_free_late(), > which is used to free reserved ranges after memblock_free_all() has > run. memblock_free_all() initializes all pages in reserved ranges, and To be precise, memblock_free_all() frees pages, or releases them to the pages allocator, rather than initializes. > accordingly, those pages are not touched by the deferred init > process. This means that currently, if the pages that > memblock_free_late() intends to release are in the deferred range, they > will never be released to the buddy allocator. They will forever be > reserved. > > In addition, memblock_free_pages() calls kmsan_memblock_free_pages(), > which is also correct for free pages but is not correct for reserved > pages. KMSAN metadata for reserved pages is initialized by > kmsan_init_shadow(), which runs shortly before memblock_free_all(). > > For both of these reasons, memblock_free_pages() should only be called > for free pages, and memblock_free_late() should call __free_pages_core() > directly instead. Overall looks fine to me and I couldn't spot potential issues. I'd appreciate if you add a paragraph about the actual issue with EFI boot you described in the cover letter to the commit message. > Fixes: 3a80a7fa7989 ("mm: meminit: initialise a subset of struct pages if CONFIG_DEFERRED_STRUCT_PAGE_INIT is set") > Signed-off-by: Aaron Thompson > --- > mm/memblock.c | 2 +- > tools/testing/memblock/internal.h | 4 ++++ > 2 files changed, 5 insertions(+), 1 deletion(-) > > diff --git a/mm/memblock.c b/mm/memblock.c > index 511d4783dcf1..56a5b6086c50 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -1640,7 +1640,7 @@ void __init memblock_free_late(phys_addr_t base, phys_addr_t size) > end = PFN_DOWN(base + size); > > for (; cursor < end; cursor++) { > - memblock_free_pages(pfn_to_page(cursor), cursor, 0); > + __free_pages_core(pfn_to_page(cursor), 0); Please add a comment that explains why it is safe to call __free_pages_core() here. Something like /* * Reserved pages are always initialized by the end of * memblock_free_all() either during memmap_init() or, with deferred * initialization if struct page in reserve_bootmem_region() */ > totalram_pages_inc(); > } > } > diff --git a/tools/testing/memblock/internal.h b/tools/testing/memblock/internal.h > index fdb7f5db7308..85973e55489e 100644 > --- a/tools/testing/memblock/internal.h > +++ b/tools/testing/memblock/internal.h > @@ -15,6 +15,10 @@ bool mirrored_kernelcore = false; > > struct page {}; > > +void __free_pages_core(struct page *page, unsigned int order) > +{ > +} > + > void memblock_free_pages(struct page *page, unsigned long pfn, > unsigned int order) > { > -- > 2.30.2 > -- Sincerely yours, Mike.