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=-9.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 EE585C433F5 for ; Thu, 16 Sep 2021 14:38:49 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B520761214 for ; Thu, 16 Sep 2021 14:38:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org B520761214 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=MKGN2+PGyuIJ3DA56iwnl14J7OQNjP0ggz0apZN47y8=; b=0d6c81j6DUJHO9 d+6kcKs30jjaEoP+zGOiOX5DBXuvWMqPO/50j0NT8rDCdCmTBEC9OQM1TvUjw4AznyV9rpKhwvd7E LfooAm+FFaOWfPkXczHjozIl9AS4rGziJEP34yMfC+SsfZUSD/mUDAKdc2yxV1AgaSHEiDyll6EWu hvdXPPfRodhA+PbibiPssyldpxMp97/vrBFc0SuOy5KWibJOkKDkm30PEWPPZo0Daev2Yp2W4Wfoj 3j5n0w3iPyCdF6Q4Ae+bUrPkpmGV7VqyxVYgk1Ud5FHkG8/xFBuyX9nVkUCZpieDlbf2Fz56lPop0 VGaj0yglKA+LDMBg5C9Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQsVu-00BLHZ-BD; Thu, 16 Sep 2021 14:37:22 +0000 Received: from mail.kernel.org ([198.145.29.99]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mQsT7-00BJnV-Am for linux-arm-kernel@lists.infradead.org; Thu, 16 Sep 2021 14:34:30 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 21B94611F2; Thu, 16 Sep 2021 14:34:27 +0000 (UTC) Date: Thu, 16 Sep 2021 15:34:25 +0100 From: Catalin Marinas To: Anshuman Khandual Cc: linux-arm-kernel@lists.infradead.org, Will Deacon , James Morse , linux-kernel@vger.kernel.org Subject: Re: [PATCH] arm64/mm/hotplug: Warn when memory limit has been reduced Message-ID: References: <1631602270-29215-1-git-send-email-anshuman.khandual@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1631602270-29215-1-git-send-email-anshuman.khandual@arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210916_073429_438754_DADB5900 X-CRM114-Status: GOOD ( 21.59 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, Sep 14, 2021 at 12:21:10PM +0530, Anshuman Khandual wrote: > If the max memory limit has been reduced with 'mem=' kernel command line > option, there might be UEFI memory map described memory beyond that limit > which could be hot removed. This might be problematic for subsequent kexec > kernel which could just access such removed memory. > > Memory offline notifier exists because there is no other way to block the > removal of boot memory, only the offlining (which isn't actually a problem) > But with 'mem=', there is no chance to stop such boot memory being offlined > as it where never in use by the kernel. As 'mem=' is a debug only option on > arm64 platform, just warn for such a situation and move on. Just to make sure I understand, is the memory beyond the mem= limit considered online by the core code and it can be subsequently offlined? Looking at walk_system_ram_range(), it doesn't seem to care about the removed memblock ranges. Would such memory beyond the mem= limit need to have been onlined first? > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index cfd9deb347c3..7ac39ee876c3 100644 > --- a/arch/arm64/mm/mmu.c > +++ b/arch/arm64/mm/mmu.c > @@ -1627,6 +1627,18 @@ static int __init prevent_bootmem_remove_init(void) > if (!IS_ENABLED(CONFIG_MEMORY_HOTREMOVE)) > return ret; > > + if (has_mem_limit_reduced()) { > + /* > + * Physical memory limit has been reduced via the 'mem=' kernel > + * command line option. Memory beyond reduced limit could now be > + * removed and reassigned (guest ?) transparently to the kernel. > + * This might cause subsequent kexec kernel to crash or at least > + * corrupt the memory when accessing UEFI memory map enumerated > + * boot memory which might have been repurposed. > + */ > + pr_warn("Memory limit reduced, kexec might be problematic\n"); > + } I'd actually move the warning to hotplug notifier callback rather than the init function. I'd also make it pr_warn_once(). -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel