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 06CC0C433EF for ; Tue, 7 Jun 2022 14:49:54 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 793346B0072; Tue, 7 Jun 2022 10:49:53 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 744BC6B0073; Tue, 7 Jun 2022 10:49:53 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5E3A16B0074; Tue, 7 Jun 2022 10:49:53 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 4C9666B0072 for ; Tue, 7 Jun 2022 10:49:53 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 20665D50 for ; Tue, 7 Jun 2022 14:49:53 +0000 (UTC) X-FDA: 79551724266.27.6C33A27 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf14.hostedemail.com (Postfix) with ESMTP id 9E0EB10004F for ; Tue, 7 Jun 2022 14:49:51 +0000 (UTC) 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 ams.source.kernel.org (Postfix) with ESMTPS id E79BCB82025 for ; Tue, 7 Jun 2022 14:49:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id AFE02C34115 for ; Tue, 7 Jun 2022 14:49:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1654613389; bh=21Q6z4C7gLAJxDrMjpR35TaWJleKEVSnTcJc1XoghQY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=WYB46EnJQ8KmDZFu6jSEUXfmMoEna05up4CJncyNZI8uwIsHCdYLTKRC0+amkX8Oj MulYqkmJUA5xdzBLnlJ21Knk2rVOc1evBYmVmwsz4nrwG0eEcpPi7TeRtjNt61KxNH ccUjQNum/v+Ub+BowdrQm3vPx9vFs8vP3DY+hXLw6mwabo8XB7Rxm9sNnN0iS1uWFt MCOberJ0KBzQM0XYyIpd9+CCCedeK4LgO49Mt/bgctMQbCdSeaqZNeB83IrXJR28LR KWDkX7QpyE+RWe5J/rqQ+SXWifk/MNU4VEaxvRBiJnHsZjTRfkssXiFrUar+JjE+ED LRsfm30v4ZsqQ== Received: by mail-yb1-f170.google.com with SMTP id x187so3983454ybe.2 for ; Tue, 07 Jun 2022 07:49:49 -0700 (PDT) X-Gm-Message-State: AOAM533oiWNRdW3mc+WnrjVWOmiKYHz/u/GNe35tJ8EO+AG4YdykuU5y 6pjlTu9fSfo9No8V+/eA9avteeHLHrPEXRrm2Lo= X-Google-Smtp-Source: ABdhPJzju8BnufR6dAUwCuaVy7emdCBqao+Rd1rppQ3NzXkq8vagt8De7zdNBr5XdK5Y5+FNyl+7NFE6w3IjeLs4C7w= X-Received: by 2002:a9d:76d5:0:b0:60b:1882:78bd with SMTP id p21-20020a9d76d5000000b0060b188278bdmr12748793otl.71.1654613377932; Tue, 07 Jun 2022 07:49:37 -0700 (PDT) MIME-Version: 1.0 References: <20220607093805.1354256-1-mawupeng1@huawei.com> <20220607093805.1354256-6-mawupeng1@huawei.com> <99900b31-2605-2c85-a1b7-9ef2666b58da@redhat.com> In-Reply-To: <99900b31-2605-2c85-a1b7-9ef2666b58da@redhat.com> From: Ard Biesheuvel Date: Tue, 7 Jun 2022 16:49:24 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 5/6] mm: Add mirror flag back on initrd memory To: David Hildenbrand Cc: Wupeng Ma , corbet@lwn.net, will@kernel.org, catalin.marinas@arm.com, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, dvhart@infradead.org, andy@infradead.org, rppt@kernel.org, akpm@linux-foundation.org, paul.walmsley@sifive.com, palmer@dabbelt.com, aou@eecs.berkeley.edu, paulmck@kernel.org, keescook@chromium.org, songmuchun@bytedance.com, rdunlap@infradead.org, damien.lemoal@opensource.wdc.com, swboyd@chromium.org, wei.liu@kernel.org, robin.murphy@arm.com, anshuman.khandual@arm.com, thunder.leizhen@huawei.com, wangkefeng.wang@huawei.com, gpiccoli@igalia.com, chenhuacai@kernel.org, geert@linux-m68k.org, chenzhou10@huawei.com, vijayb@linux.microsoft.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-efi@vger.kernel.org, platform-driver-x86@vger.kernel.org, linux-mm@kvack.org, linux-riscv@lists.infradead.org Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: k4g35c6eujobxrnwndgx99qixz6417ru X-Rspam-User: Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=WYB46EnJ; spf=pass (imf14.hostedemail.com: domain of ardb@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=ardb@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 9E0EB10004F X-HE-Tag: 1654613391-618450 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 Tue, 7 Jun 2022 at 14:22, David Hildenbrand wrote: > > On 07.06.22 11:38, Wupeng Ma wrote: > > From: Ma Wupeng > > > > Initrd memory will be removed and then added in arm64_memblock_init() and this > > will cause it to lose all of its memblock flags. The lost of MEMBLOCK_MIRROR > > flag will lead to error log printed by find_zone_movable_pfns_for_nodes if > > the lower 4G range has some non-mirrored memory. > > > > In order to solve this problem, the lost MEMBLOCK_MIRROR flag will be > > reinstalled if the origin memblock has this flag. > > > > Signed-off-by: Ma Wupeng > > --- > > arch/arm64/mm/init.c | 9 +++++++++ > > include/linux/memblock.h | 1 + > > mm/memblock.c | 20 ++++++++++++++++++++ > > 3 files changed, 30 insertions(+) > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > index 339ee84e5a61..11641f924d08 100644 > > --- a/arch/arm64/mm/init.c > > +++ b/arch/arm64/mm/init.c > > @@ -350,9 +350,18 @@ void __init arm64_memblock_init(void) > > "initrd not fully accessible via the linear mapping -- please check your bootloader ...\n")) { > > phys_initrd_size = 0; > > } else { > > + int flags, ret; > > + > > + ret = memblock_get_flags(base, &flags); > > + if (ret) > > + flags = 0; > > + > > memblock_remove(base, size); /* clear MEMBLOCK_ flags */ > > memblock_add(base, size); > > memblock_reserve(base, size); > > Can you explain why we're removing+re-adding here exactly? Is it just to > clear flags as the comment indicates? > This should only happen if the placement of the initrd conflicts with a mem= command line parameter or it is not covered by memblock for some other reason. IOW, this should never happen, and if re-memblock_add'ing this memory unconditionally is causing problems, we should fix that instead of working around it. > If it's really just about clearing flags, I wonder if we rather want to > have an interface that does exactly that, and hides the way this is > actually implemented (obtain flags, remove, re-add ...), internally. > > But most probably there is more magic in the code and clearing flags > isn't all it ends up doing. > I don't remember exactly why we needed to clear the flags, but I think it had to do with some corner case we hit when the initrd was partially covered.