From patchwork Wed Jun 5 08:20:49 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Rapoport X-Patchwork-Id: 13686395 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 77B0CC25B76 for ; Wed, 5 Jun 2024 08:21:12 +0000 (UTC) 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:MIME-Version:Message-ID:Date:Subject:Cc :To:From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=YHGY8NsUi6VbxQvdiPzgvK63lkWLcf/cPpl26YFS4yI=; b=hoIFuKobs47ma2 iZ5bFx1Zkz/7wpKTHL/1ZtN1HcJbMJOC9pNUktngl+W2Fu3Y6BbLoe7/L43zMt8vTIasrPgRHJlFc lJLv5BHccnJEDd0DuWRWFzdhUJnWN9U9RnRMDBH7e5pNoFE4II1dTZ4m6Zgl5PGspxqGvoseio+7x ifI6GW89ZSGGTD0skjTDtg1sShCZk5Fb12iRc/m4eah44bkSx5JBOUVPQgB6LrUMFZrkso3Mt8yg8 UiLgN0DJP76wU7Yg1B35V6GwhSzYMJ0ikCZzy3BcKG+9RrttOL7lKzOhritECtggLJ1X1mVBPWG77 9EisylUKXgWAxaJXUmyg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEltI-00000005AlP-2w1J; Wed, 05 Jun 2024 08:21:04 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sEltG-00000005Ajr-0ez0 for linux-arm-kernel@lists.infradead.org; Wed, 05 Jun 2024 08:21:03 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 4B5A1CE0E0D; Wed, 5 Jun 2024 08:21:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 47CCCC3277B; Wed, 5 Jun 2024 08:20:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717575659; bh=EvHXfhJQo+1JIqkLSowLXdMVi7K/zBiTFwHkny2F8S0=; h=From:To:Cc:Subject:Date:From; b=qyBOBK7cnJQladW5TQw2rznQKowkIacm0mTY+DLi/jT2RLbrOFvImnRVB661krn81 BFfOoVmz/QCe1WWDVFZjO9dwIkzShfDFsEdEO57/N8GFKEC9C96ejBpMx7fd563YXp z4StBme/imqe4LbfZu+N7L26DuD5PdhzERA2wJxJZ9VoljFnpBTex9iA4oESwMjYlv bhZtLoECi7uCqu8TMZ9VDbFgnt5nEKyZIoa1sg7/I5AwuFa9Gm2dHWwmaAVpzwBZWr QwKj+US/JqXqNGOcuLJOUB8a3SJIR9u4z/PvwHbxo2szvwiU3XajoUiHcV1dcnwZfz b0ipyN9GKjsoQ== From: Mike Rapoport To: linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Jonathan Cameron , Mike Rapoport , Oscar Salvador , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.org Subject: [PATCH] mm/memory_hotplug: Drop memblock_phys_free() call in try_remove_memory() Date: Wed, 5 Jun 2024 11:20:49 +0300 Message-ID: <20240605082049.973242-1-rppt@kernel.org> X-Mailer: git-send-email 2.43.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240605_012102_413463_DC09E8FD X-CRM114-Status: GOOD ( 11.23 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org From: Jonathan Cameron The call for memblock_phys_free() in try_remove_memory() does not balance any call to memblock_alloc() (or memblock_reserve() for that matter). There are no memblock_reserve() calls in mm/memory_hotplug.c, no memblock allocations possible after mm_core_init(), and even if memblock_add_node() called from add_memory_resource() would need to allocate memory, that memory would ba allocated from slab. The patch f9126ab9241f ("memory-hotplug: fix wrong edge when hot add a new node") that introduced that call to memblock_free() does not provide adequate description why that was required and tinkering with memblock in the context of memory hotplug on x86 seems bogus because x86 never kept memblock after boot anyway. Drop memblock_phys_free() call in try_remove_memory(). Signed-off-by: Jonathan Cameron [rppt: rewrite the commit message] Signed-off-by: Mike Rapoport (IBM) Acked-by: David Hildenbrand Acked-by: Oscar Salvador Acked-by: Oscar Salvador --- mm/memory_hotplug.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c index 431b1f6753c0..e0d49f128e0d 100644 --- a/mm/memory_hotplug.c +++ b/mm/memory_hotplug.c @@ -2283,10 +2283,8 @@ static int __ref try_remove_memory(u64 start, u64 size) remove_memory_blocks_and_altmaps(start, size); } - if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) { - memblock_phys_free(start, size); + if (IS_ENABLED(CONFIG_ARCH_KEEP_MEMBLOCK)) memblock_remove(start, size); - } release_mem_region_adjustable(start, size);