[{"id":3681366,"web_url":"http://patchwork.ozlabs.org/comment/3681366/","msgid":"","date":"2026-04-23T10:38:27","subject":"Re: [PATCH v5 v5 2/6] mm/memory_hotplug: Fix incorrect altmap passing\n in error path","submitter":{"id":92023,"url":"http://patchwork.ozlabs.org/api/people/92023/","name":"David Hildenbrand (Arm)","email":"david@kernel.org"},"content":"On 4/23/26 09:19, Muchun Song wrote:\n> In create_altmaps_and_memory_blocks(), when arch_add_memory() succeeds\n> with memmap_on_memory enabled, the vmemmap pages are allocated from\n> params.altmap. If create_memory_block_devices() subsequently fails, the\n> error path calls arch_remove_memory() with a NULL altmap instead of\n> params.altmap.\n> \n> This is a bug that could lead to memory corruption. Since altmap is\n> NULL, vmemmap_free() falls back to freeing the vmemmap pages into the\n> system buddy allocator via free_pages() instead of the altmap.\n> arch_remove_memory() then immediately destroys the physical linear\n> mapping for this memory. This injects unowned pages into the buddy\n> allocator, causing machine checks or memory corruption if the system\n> later attempts to allocate and use those freed pages.\n> \n> Fix this by passing params.altmap to arch_remove_memory() in the error\n> path.\n> \n> Fixes: 6b8f0798b85a (\"mm/memory_hotplug: split memmap_on_memory requests across memblocks\")\n> Signed-off-by: Muchun Song \n> ---\n> mm/memory_hotplug.c | 2 +-\n> 1 file changed, 1 insertion(+), 1 deletion(-)\n> \n> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\n> index 2a943ec57c85..0bad2aed2bde 100644\n> --- a/mm/memory_hotplug.c\n> +++ b/mm/memory_hotplug.c\n> @@ -1468,7 +1468,7 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n> \t\tret = create_memory_block_devices(cur_start, memblock_size, nid,\n> \t\t\t\t\t\t params.altmap, group);\n> \t\tif (ret) {\n> -\t\t\tarch_remove_memory(cur_start, memblock_size, NULL);\n> +\t\t\tarch_remove_memory(cur_start, memblock_size, params.altmap);\n> \t\t\tkfree(params.altmap);\n> \t\t\tgoto out;\n> \t\t}\n\nYeah, that's nasty. We should CC stable.\n\nAcked-by: David Hildenbrand (Arm) \n\n\n\nShould we extend the safety checks we already have on the other path?\n\n\ndiff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\nindex 2a943ec57c85..1c304468af08 100644\n--- a/mm/memory_hotplug.c\n+++ b/mm/memory_hotplug.c\n@@ -1402,6 +1402,12 @@ bool mhp_supports_memmap_on_memory(void)\n }\n EXPORT_SYMBOL_GPL(mhp_supports_memmap_on_memory);\n \n+static void altmap_free(struct vmemmap_altmap *altmap)\n+{\n+ WARN(altmap->alloc, \"Altmap not fully unmapped\");\n+ kfree(altmap);\n+}\n+\n static void remove_memory_blocks_and_altmaps(u64 start, u64 size)\n {\n unsigned long memblock_size = memory_block_size_bytes();\n@@ -1426,10 +1432,7 @@ static void remove_memory_blocks_and_altmaps(u64 start, u64 size)\n remove_memory_block_devices(cur_start, memblock_size);\n \n arch_remove_memory(cur_start, memblock_size, altmap);\n-\n- /* Verify that all vmemmap pages have actually been freed. */\n- WARN(altmap->alloc, \"Altmap not fully unmapped\");\n- kfree(altmap);\n+ altmap_free(altmap);\n }\n }\n \n@@ -1460,7 +1463,7 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n /* call arch's memory hotadd */\n ret = arch_add_memory(nid, cur_start, memblock_size, ¶ms);\n if (ret < 0) {\n- kfree(params.altmap);\n+ altmap_free(params.altmap);\n goto out;\n }\n \n@@ -1469,13 +1472,12 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n params.altmap, group);\n if (ret) {\n arch_remove_memory(cur_start, memblock_size, NULL);\n- kfree(params.altmap);\n+ altmap_free(params.altmap);\n goto out;\n }\n }\n \n return 0;\n-out:\n if (ret && cur_start != start)\n remove_memory_blocks_and_altmaps(start, cur_start - start);\n return ret;\n\n\nMaybe the helper should even go into altmap code? Not sure.","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=NOGs+0Jr;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20001-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=172.234.252.31","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=NOGs+0Jr;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=172.234.252.31; helo=sea.source.kernel.org;\n envelope-from=david@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature ECDSA (secp384r1 raw public key)\n server-digest SHA384)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1Xcv4gJrz1yD5\n\tfor ; Thu, 23 Apr 2026 20:38:39 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g1Xct39NLz2yFQ;\n\tThu, 23 Apr 2026 20:38:38 +1000 (AEST)","from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g1Xcs1mLtz2y8d\n\tfor ; Thu, 23 Apr 2026 20:38:37 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby sea.source.kernel.org (Postfix) with ESMTP id 562DD40566;\n\tThu, 23 Apr 2026 10:38:34 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id 206FFC2BCAF;\n\tThu, 23 Apr 2026 10:38:28 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1776940718;\n\tcv=none;\n b=iS2ta2QUZvVrhd1dN78th6GkcednAhlYoLi4De6JcY/pfqMMNbG4oZeh07TZOhKOkJC50/23CSZRkeDCP6BTgVxLemqbHcq5m8zZUMUys/yJoubPjChTtLO1u+Kc3rskcoYr4TWELIzmb/aanDxki80ghvVBmbQIbyPOqB7gF+vvcPLnqhYUQ67fHQzmyGvP1IntvJbvykamyK4NgRRuNuxNfkRaEHuUoI7jCuRcC2WEKfQW1hWdMTNnCkvvycS0b6Ip8bewRW9VL5b7Dc6lVF1SUXwP/1OTbzO/Wuz7DccXm00ICCs5oksXgj+KPSPkoYY3siMPg+eMxxIu5DDFqA==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1776940718; c=relaxed/relaxed;\n\tbh=haIdrYWGrTuwiLse2hZYYcuWW2obGUZovwL6KO1WjhQ=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=OAhd9rpqr4Q9TujVqCJUzppHDi4zAtR0AUvtVerz/aMTHGlF7WSWXK3gzSk19FIq8MlkOTqGy61VocuU7s01IBvS2JJoRi05dtScvF3e92x2ShY1uVS4MVIts9RRQqGqqKP51J5wkXkk5BPwUpUBasW38BzNA7n864qBl4TZUee2U5rD5J3ANcmtuEtk89T2fDsNIeRwKN5KggVGWRoOcaB1bBLH4epJto79V5QVK6M4G99VwtdfGXliNcFoVmUa1y2/ykUTUSszQ5VRD8XegAvOuWAWYHbbDKQLECJSmla81Us1lmrHnjBAuRWsdPQ8ItsN8gmra7B4L9ZBboofsg==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=NOGs+0Jr; dkim-atps=neutral;\n spf=pass (client-ip=172.234.252.31; helo=sea.source.kernel.org;\n envelope-from=david@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1776940714;\n\tbh=OykCGngjeVXxh+S5FhihKYrlA0mMJyXZVqRb3yjbltQ=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=NOGs+0JrJ4V2SyqOjrtFCQhLPr6YNzdn9bI3as6PXFB7UQwCHKiLnzRPHyEUcB7ZN\n\t VKGOTXW/gkIMWlDZFdEi6oECp+yHwo4lAx3NokhIMuokGolZjyGr/nsVX3mbl/27Vo\n\t v7/vhuCEqkUK7uPz7wPEiT6mcRIUBnH2DMkpiEu/tktjWePw9DsAs0KodWlI72iVDz\n\t H0ITnKBGxvzcxasSWRZcfAXV5DGRFsTtMbzeNb5VyCC7xt43PWdQ0Qj1iPKl7saBqy\n\t 3FJRdZzjsfdBx5KUS9/me1V0pBiumh481fCG5n7UpmfcuKvquCsHIESxS8bpeMWIdr\n\t KGrBrssiZK2cA==","Message-ID":"","Date":"Thu, 23 Apr 2026 12:38:27 +0200","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"","List-Help":"","List-Owner":"","List-Post":"","List-Archive":",\n ","List-Subscribe":",\n ,\n ","List-Unsubscribe":"","Precedence":"list","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v5 v5 2/6] mm/memory_hotplug: Fix incorrect altmap passing\n in error path","To":"Muchun Song ,\n Andrew Morton ,\n Muchun Song , Oscar Salvador ,\n Michael Ellerman ,\n Madhavan Srinivasan ","Cc":"Lorenzo Stoakes ,\n \"Liam R . Howlett\" ,\n Vlastimil Babka , Mike Rapoport ,\n Suren Baghdasaryan , Michal Hocko ,\n Nicholas Piggin , Christophe Leroy ,\n aneesh.kumar@linux.ibm.com, joao.m.martins@oracle.com, linux-mm@kvack.org,\n linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org","References":"<20260423071911.1962859-1-songmuchun@bytedance.com>\n <20260423071911.1962859-3-songmuchun@bytedance.com>","From":"\"David Hildenbrand (Arm)\" ","Content-Language":"en-US","Autocrypt":"addr=david@kernel.org; keydata=\n xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ\n dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL\n QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp\n XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK\n Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9\n PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt\n WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc\n UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv\n jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb\n B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk\n ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik\n AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN\n 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD\n g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz\n ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x\n 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7\n /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4\n jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ\n DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R\n HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC\n 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7\n LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR\n 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt\n VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk\n /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy\n iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ\n 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21\n zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg\n azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY\n FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D\n sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO\n 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e\n EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts\n IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC\n 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV\n Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS\n sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx\n yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9\n 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg\n r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ\n 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ\n CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY\n qIws/H2t","In-Reply-To":"<20260423071911.1962859-3-songmuchun@bytedance.com>","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3681423,"web_url":"http://patchwork.ozlabs.org/comment/3681423/","msgid":"","date":"2026-04-23T12:18:15","subject":"Re: [PATCH v5 v5 2/6] mm/memory_hotplug: Fix incorrect altmap passing\n in error path","submitter":{"id":84878,"url":"http://patchwork.ozlabs.org/api/people/84878/","name":"Muchun Song","email":"muchun.song@linux.dev"},"content":"> On Apr 23, 2026, at 18:38, David Hildenbrand (Arm) wrote:\n> \n> On 4/23/26 09:19, Muchun Song wrote:\n>> In create_altmaps_and_memory_blocks(), when arch_add_memory() succeeds\n>> with memmap_on_memory enabled, the vmemmap pages are allocated from\n>> params.altmap. If create_memory_block_devices() subsequently fails, the\n>> error path calls arch_remove_memory() with a NULL altmap instead of\n>> params.altmap.\n>> \n>> This is a bug that could lead to memory corruption. Since altmap is\n>> NULL, vmemmap_free() falls back to freeing the vmemmap pages into the\n>> system buddy allocator via free_pages() instead of the altmap.\n>> arch_remove_memory() then immediately destroys the physical linear\n>> mapping for this memory. This injects unowned pages into the buddy\n>> allocator, causing machine checks or memory corruption if the system\n>> later attempts to allocate and use those freed pages.\n>> \n>> Fix this by passing params.altmap to arch_remove_memory() in the error\n>> path.\n>> \n>> Fixes: 6b8f0798b85a (\"mm/memory_hotplug: split memmap_on_memory requests across memblocks\")\n>> Signed-off-by: Muchun Song \n>> ---\n>> mm/memory_hotplug.c | 2 +-\n>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>> \n>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\n>> index 2a943ec57c85..0bad2aed2bde 100644\n>> --- a/mm/memory_hotplug.c\n>> +++ b/mm/memory_hotplug.c\n>> @@ -1468,7 +1468,7 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n>> \tret = create_memory_block_devices(cur_start, memblock_size, nid,\n>> \t\t\t\t\tparams.altmap, group);\n>> \tif (ret) {\n>> - \t\tarch_remove_memory(cur_start, memblock_size, NULL);\n>> + \t\tarch_remove_memory(cur_start, memblock_size, params.altmap);\n>> \t\tkfree(params.altmap);\n>> \t\tgoto out;\n>> \t}\n> \n> Yeah, that's nasty. We should CC stable.\n\nMake sense.\n\n> \n> Acked-by: David Hildenbrand (Arm) \n\nThanks.\n\n> \n> \n> \n> Should we extend the safety checks we already have on the other path?\n\nBetter to have.\n\n> \n> \n> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\n> index 2a943ec57c85..1c304468af08 100644\n> --- a/mm/memory_hotplug.c\n> +++ b/mm/memory_hotplug.c\n> @@ -1402,6 +1402,12 @@ bool mhp_supports_memmap_on_memory(void)\n> }\n> EXPORT_SYMBOL_GPL(mhp_supports_memmap_on_memory);\n> \n> +static void altmap_free(struct vmemmap_altmap *altmap)\n> +{\n> + WARN(altmap->alloc, \"Altmap not fully unmapped\");\n\nShould we change it to WARN_ONCE?\n\n> + kfree(altmap);\n> +}\n> +\n> static void remove_memory_blocks_and_altmaps(u64 start, u64 size)\n> {\n> unsigned long memblock_size = memory_block_size_bytes();\n> @@ -1426,10 +1432,7 @@ static void remove_memory_blocks_and_altmaps(u64 start, u64 size)\n> remove_memory_block_devices(cur_start, memblock_size);\n> \n> arch_remove_memory(cur_start, memblock_size, altmap);\n> -\n> - /* Verify that all vmemmap pages have actually been freed. */\n> - WARN(altmap->alloc, \"Altmap not fully unmapped\");\n> - kfree(altmap);\n> + altmap_free(altmap);\n> }\n> }\n> \n> @@ -1460,7 +1463,7 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n> /* call arch's memory hotadd */\n> ret = arch_add_memory(nid, cur_start, memblock_size, ¶ms);\n> if (ret < 0) {\n> - kfree(params.altmap);\n> + altmap_free(params.altmap);\n> goto out;\n> }\n> \n> @@ -1469,13 +1472,12 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n> params.altmap, group);\n> if (ret) {\n> arch_remove_memory(cur_start, memblock_size, NULL);\n> - kfree(params.altmap);\n> + altmap_free(params.altmap);\n> goto out;\n> }\n> }\n> \n> return 0;\n> -out:\n> if (ret && cur_start != start)\n> remove_memory_blocks_and_altmaps(start, cur_start - start);\n> return ret;\n> \n> \n> Maybe the helper should even go into altmap code? Not sure.\n\nI think the current changes look great as they are. While I believe this is valuable\nas a standalone cleanup, what do you think?\n\nThanks,\nMuchun.\n\n> \n> \n> -- \n> Cheers,\n> \n> David","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=E64lGpsK;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20009-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=\"2001:41d0:1004:224b::ba\"","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.dev","lists.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=E64lGpsK;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=linux.dev\n (client-ip=2001:41d0:1004:224b::ba; helo=out-186.mta0.migadu.com;\n envelope-from=muchun.song@linux.dev; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1b0f6RJRz1y2d\n\tfor ; Thu, 23 Apr 2026 22:25:54 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g1b0f3YD5z2yGf;\n\tThu, 23 Apr 2026 22:25:54 +1000 (AEST)","from out-186.mta0.migadu.com (out-186.mta0.migadu.com\n [IPv6:2001:41d0:1004:224b::ba])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g1b0b2W6qz2y8d\n\tfor ; Thu, 23 Apr 2026 22:25:50 +1000 (AEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1776947154;\n\tcv=none;\n b=nsJdOSJ7JkPUB1XUSf/PTzwGSc3sNteo0Xb5JMJ/0ca9NV0Uvv4g/EsGF4hfem6af0fyutsJLoWIqibDH5/0QMx3LavnoKdBsd9BZg7ICc4cQwOQw8l5C05Bv3xgF9lzsNYffS62kkFktfwBOag2UQK74DclhRN2dCwlXcrznkc/lnIljjuytkbKZcOaokEuWCtooPINaFeLIu6auNkIR+gtAV7DebiHyagzM/bq0vge1WyFZvXxK6Gq438jW1LZA3shlpOPffLddyUt0yuu1F//VvyskBa3tG4jLrBtUYDypzkzvHR4ST//VCCpnLCL5AE+1mmAWEQxNT36sUvUeg==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1776947154; c=relaxed/relaxed;\n\tbh=Q4LgpLetqEJMUYqZ9nmv9qSQLNKswZwmhvnZvNQKMWs=;\n\th=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:\n\t Message-Id:References:To;\n b=GUHgcEEVLb7CzUwMWhCNFl5p1uDI3b5pKZKXBTnwJf8HhAcV898/wUbwk+6VVKTaVRGUVifkw76i/Mm84Kqg/0Dth2vAme30mlmTrF0qSe6esztPo5izJzIR3KifFfGYJf40ceOQ0kCErPqEfOXiNCbAiKiDcDH4+zh4QHJcLVmKzUqeDoJoZhrJZ7qfu/k6uei0vXBvujpVZ4fUOwn22Gq06U4ItJA/CFdVJkkBv1wTuN9RDsIrS90pZ+sgqykSZSRNSgkZmSOHg2sEnjR0Pzq+lVLl2lTsB/9leYNfGK3rcNRCmBakJsWEd7e45+4lmLfOUbtp9ZTfqKQmWTrc3Q==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.dev; dkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=E64lGpsK; dkim-atps=neutral;\n spf=pass (client-ip=2001:41d0:1004:224b::ba; helo=out-186.mta0.migadu.com;\n envelope-from=muchun.song@linux.dev;\n receiver=lists.ozlabs.org) smtp.mailfrom=linux.dev","Content-Type":"text/plain;\n\tcharset=us-ascii","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;\n\tt=1776947125;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=Q4LgpLetqEJMUYqZ9nmv9qSQLNKswZwmhvnZvNQKMWs=;\n\tb=E64lGpsKIAp0+7yqcT34z/MtVPASA0p+X46tbKSZ5VzzVuD4yhmTK/MLRJyOoG5xPYXO3/\n\tbu0/dIkxxRSxYj7Wq3EhzzP/r7oe+ItOHS3YgcKc6tBrnkucgv13Ys2XocFFJkuL64Ybzo\n\t6mbLW5WEfZNLIHF24XAxEOc/41LbejE=","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"","List-Help":"","List-Owner":"","List-Post":"","List-Archive":",\n ","List-Subscribe":",\n ,\n ","List-Unsubscribe":"","Precedence":"list","Mime-Version":"1.0 (Mac OS X Mail 16.0 \\(3864.500.181\\))","Subject":"Re: [PATCH v5 v5 2/6] mm/memory_hotplug: Fix incorrect altmap passing\n in error path","X-Report-Abuse":"Please report any abuse attempt to abuse@migadu.com and\n include these headers.","From":"Muchun Song ","In-Reply-To":"","Date":"Thu, 23 Apr 2026 20:18:15 +0800","Cc":"Muchun Song ,\n Andrew Morton ,\n Oscar Salvador ,\n Michael Ellerman ,\n Madhavan Srinivasan ,\n Lorenzo Stoakes ,\n \"Liam R . Howlett\" ,\n Vlastimil Babka ,\n Mike Rapoport ,\n Suren Baghdasaryan ,\n Michal Hocko ,\n Nicholas Piggin ,\n Christophe Leroy ,\n aneesh.kumar@linux.ibm.com,\n joao.m.martins@oracle.com,\n linux-mm@kvack.org,\n linuxppc-dev@lists.ozlabs.org,\n linux-kernel@vger.kernel.org","Content-Transfer-Encoding":"quoted-printable","Message-Id":"","References":"<20260423071911.1962859-1-songmuchun@bytedance.com>\n <20260423071911.1962859-3-songmuchun@bytedance.com>\n ","To":"\"David Hildenbrand (Arm)\" ","X-Migadu-Flow":"FLOW_OUT","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_PASS,SPF_PASS autolearn=disabled\n\tversion=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3681426,"web_url":"http://patchwork.ozlabs.org/comment/3681426/","msgid":"<25aac60c-8510-4d92-85f3-368cfe9d83ef@kernel.org>","date":"2026-04-23T12:28:39","subject":"Re: [PATCH v5 v5 2/6] mm/memory_hotplug: Fix incorrect altmap passing\n in error path","submitter":{"id":92023,"url":"http://patchwork.ozlabs.org/api/people/92023/","name":"David Hildenbrand (Arm)","email":"david@kernel.org"},"content":"On 4/23/26 14:18, Muchun Song wrote:\n> \n> \n>> On Apr 23, 2026, at 18:38, David Hildenbrand (Arm) wrote:\n>>\n>> On 4/23/26 09:19, Muchun Song wrote:\n>>> In create_altmaps_and_memory_blocks(), when arch_add_memory() succeeds\n>>> with memmap_on_memory enabled, the vmemmap pages are allocated from\n>>> params.altmap. If create_memory_block_devices() subsequently fails, the\n>>> error path calls arch_remove_memory() with a NULL altmap instead of\n>>> params.altmap.\n>>>\n>>> This is a bug that could lead to memory corruption. Since altmap is\n>>> NULL, vmemmap_free() falls back to freeing the vmemmap pages into the\n>>> system buddy allocator via free_pages() instead of the altmap.\n>>> arch_remove_memory() then immediately destroys the physical linear\n>>> mapping for this memory. This injects unowned pages into the buddy\n>>> allocator, causing machine checks or memory corruption if the system\n>>> later attempts to allocate and use those freed pages.\n>>>\n>>> Fix this by passing params.altmap to arch_remove_memory() in the error\n>>> path.\n>>>\n>>> Fixes: 6b8f0798b85a (\"mm/memory_hotplug: split memmap_on_memory requests across memblocks\")\n>>> Signed-off-by: Muchun Song \n>>> ---\n>>> mm/memory_hotplug.c | 2 +-\n>>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>>>\n>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\n>>> index 2a943ec57c85..0bad2aed2bde 100644\n>>> --- a/mm/memory_hotplug.c\n>>> +++ b/mm/memory_hotplug.c\n>>> @@ -1468,7 +1468,7 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n>>> \tret = create_memory_block_devices(cur_start, memblock_size, nid,\n>>> \t\t\t\t\tparams.altmap, group);\n>>> \tif (ret) {\n>>> - \t\tarch_remove_memory(cur_start, memblock_size, NULL);\n>>> + \t\tarch_remove_memory(cur_start, memblock_size, params.altmap);\n>>> \t\tkfree(params.altmap);\n>>> \t\tgoto out;\n>>> \t}\n>>\n>> Yeah, that's nasty. We should CC stable.\n> \n> Make sense.\n> \n>>\n>> Acked-by: David Hildenbrand (Arm) \n> \n> Thanks.\n> \n>>\n>>\n>>\n>> Should we extend the safety checks we already have on the other path?\n> \n> Better to have.\n> \n>>\n>>\n>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\n>> index 2a943ec57c85..1c304468af08 100644\n>> --- a/mm/memory_hotplug.c\n>> +++ b/mm/memory_hotplug.c\n>> @@ -1402,6 +1402,12 @@ bool mhp_supports_memmap_on_memory(void)\n>> }\n>> EXPORT_SYMBOL_GPL(mhp_supports_memmap_on_memory);\n>>\n>> +static void altmap_free(struct vmemmap_altmap *altmap)\n>> +{\n>> + WARN(altmap->alloc, \"Altmap not fully unmapped\");\n> \n> Should we change it to WARN_ONCE?\n\nWas debating with myself, and yes, I think so.\n\n> \n>> + kfree(altmap);\n>> +}\n>> +\n>> static void remove_memory_blocks_and_altmaps(u64 start, u64 size)\n>> {\n>> unsigned long memblock_size = memory_block_size_bytes();\n>> @@ -1426,10 +1432,7 @@ static void remove_memory_blocks_and_altmaps(u64 start, u64 size)\n>> remove_memory_block_devices(cur_start, memblock_size);\n>>\n>> arch_remove_memory(cur_start, memblock_size, altmap);\n>> -\n>> - /* Verify that all vmemmap pages have actually been freed. */\n>> - WARN(altmap->alloc, \"Altmap not fully unmapped\");\n>> - kfree(altmap);\n>> + altmap_free(altmap);\n>> }\n>> }\n>>\n>> @@ -1460,7 +1463,7 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n>> /* call arch's memory hotadd */\n>> ret = arch_add_memory(nid, cur_start, memblock_size, ¶ms);\n>> if (ret < 0) {\n>> - kfree(params.altmap);\n>> + altmap_free(params.altmap);\n>> goto out;\n>> }\n>>\n>> @@ -1469,13 +1472,12 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n>> params.altmap, group);\n>> if (ret) {\n>> arch_remove_memory(cur_start, memblock_size, NULL);\n>> - kfree(params.altmap);\n>> + altmap_free(params.altmap);\n>> goto out;\n>> }\n>> }\n>>\n>> return 0;\n>> -out:\n>> if (ret && cur_start != start)\n>> remove_memory_blocks_and_altmaps(start, cur_start - start);\n>> return ret;\n>>\n>>\n>> Maybe the helper should even go into altmap code? Not sure.\n> \n> I think the current changes look great as they are. While I believe this is valuable\n> as a standalone cleanup, what do you think?\nMakes sense. Could you do me the favor and follow up with that, on top of the fixes?","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=PSM3c2kn;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=112.213.38.117; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20010-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=172.105.4.254","lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org","lists.ozlabs.org;\n\tdkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=PSM3c2kn;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org\n (client-ip=172.105.4.254; helo=tor.source.kernel.org;\n envelope-from=david@kernel.org; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1b493NXQz1y2d\n\tfor ; Thu, 23 Apr 2026 22:28:57 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g1b486C0Lz2yGf;\n\tThu, 23 Apr 2026 22:28:56 +1000 (AEST)","from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g1b415sjXz2y8d\n\tfor ; Thu, 23 Apr 2026 22:28:49 +1000 (AEST)","from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58])\n\tby tor.source.kernel.org (Postfix) with ESMTP id CB5386014B;\n\tThu, 23 Apr 2026 12:28:46 +0000 (UTC)","by smtp.kernel.org (Postfix) with ESMTPSA id D0860C2BCB3;\n\tThu, 23 Apr 2026 12:28:41 +0000 (UTC)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1776947336;\n\tcv=none;\n b=dLCSCoUGmIHT1IHDJGMfbkeLnMK0hPsbN1+bRoaVGFViu9MqymxUEbYV4koCCNby2HzKvh0wNcqFbCgg2GVkJFWvRu+wzOftNL6sMtQevJE8nUv+ggXSi1UKAMnNXcv8M5/SSVkG6mufE2C/o0GW2Xsrh7AAceOBqlpaOhwcDecRGOMSQJal73KWdTVwEbbMPv2BfzfX0sBRnwiPk1Fh052mHdKkT8UeBXcsoalIvvmAPEVwgYKYXDYH08gFE8nThB8MCzNB6oV699RSdqqTnscKFjb6I/Lds3F26UZ7D8GTL0LRgSrZOac14SqUz+X04ph9Au25cJhL1QCEeOO9uQ==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1776947336; c=relaxed/relaxed;\n\tbh=sG5ghfu2jFC4aldxD3kxvORSzXSDLLT86Yp0ZXVbsX0=;\n\th=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:\n\t In-Reply-To:Content-Type;\n b=SKcW5Dh7AXTuYUFgir40c8ke1KWVCNUNLrioliG+fiUd+ksOrx2oKdRURlB58yqAbe51wMXz39WpGQZCXWPptbK36Ba+biFEmu4Lq8Svc0cU7eex4ooEOEYt2Vh6WDciGfWePucUIN/MGKBdYxvctfpk142teDVuL89qhXnA9XMlj6bi6CVLaoenmGuh2ESudQgp3hgfc1Vf4U+CkqlytyH6+unRgyYko+oysb1C2nqSuIzHFGhjSpCl5vGAAG5eh2Djj/iF3W7FsH1A0CAD3DjxNRAW5Ramtk3EX9NvGXwnKUOMZovyxzjOdTlvJIAKxPPnm6FFPx1ynD+yXrAqzQ==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=quarantine dis=none) header.from=kernel.org;\n dkim=pass (2048-bit key;\n unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256\n header.s=k20201202 header.b=PSM3c2kn; dkim-atps=neutral;\n spf=pass (client-ip=172.105.4.254; helo=tor.source.kernel.org;\n envelope-from=david@kernel.org;\n receiver=lists.ozlabs.org) smtp.mailfrom=kernel.org","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;\n\ts=k20201202; t=1776947326;\n\tbh=WcCQRAneXN0yo79vQq3fLMIsGEAKpO1QE2YHg9kqD7s=;\n\th=Date:Subject:To:Cc:References:From:In-Reply-To:From;\n\tb=PSM3c2knXTOwKhpHZ3jsKxgcWqqu7WR/VLqIlkdtlTrj2urvm5dfJhR4G4fEAwZjo\n\t kGacdtrfSH/1ysad2N/z3vSTegBdHt89r2CuMCwUMGEevOjAwgBojl4nZg33QoLFKH\n\t MSVdvQ7LDdF+39xjy/fe37m7drmazUXXFIGGOtwPDlyHpwEVSUlpTkDalc2bZBpk+L\n\t BWK2/7nhTK9cncPANlpebpoABAofbVKJkIPOPEQnibia1qF41hI0e1GhrPz4/BbnET\n\t o8jFO0uZ+eW+GQhpY/qxW0JptPeYcLYpCH40hCUZ/iBdMJoZJNfJlq8vwNZxetzkf7\n\t EfSR6DU0Wg+eg==","Message-ID":"<25aac60c-8510-4d92-85f3-368cfe9d83ef@kernel.org>","Date":"Thu, 23 Apr 2026 14:28:39 +0200","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"","List-Help":"","List-Owner":"","List-Post":"","List-Archive":",\n ","List-Subscribe":",\n ,\n ","List-Unsubscribe":"","Precedence":"list","MIME-Version":"1.0","User-Agent":"Mozilla Thunderbird","Subject":"Re: [PATCH v5 v5 2/6] mm/memory_hotplug: Fix incorrect altmap passing\n in error path","To":"Muchun Song ","Cc":"Muchun Song ,\n Andrew Morton , Oscar Salvador\n , Michael Ellerman ,\n Madhavan Srinivasan , Lorenzo Stoakes ,\n \"Liam R . Howlett\" ,\n Vlastimil Babka , Mike Rapoport ,\n Suren Baghdasaryan , Michal Hocko ,\n Nicholas Piggin , Christophe Leroy ,\n aneesh.kumar@linux.ibm.com, joao.m.martins@oracle.com, linux-mm@kvack.org,\n linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org","References":"<20260423071911.1962859-1-songmuchun@bytedance.com>\n <20260423071911.1962859-3-songmuchun@bytedance.com>\n \n ","From":"\"David Hildenbrand (Arm)\" ","Content-Language":"en-US","Autocrypt":"addr=david@kernel.org; keydata=\n xsFNBFXLn5EBEAC+zYvAFJxCBY9Tr1xZgcESmxVNI/0ffzE/ZQOiHJl6mGkmA1R7/uUpiCjJ\n dBrn+lhhOYjjNefFQou6478faXE6o2AhmebqT4KiQoUQFV4R7y1KMEKoSyy8hQaK1umALTdL\n QZLQMzNE74ap+GDK0wnacPQFpcG1AE9RMq3aeErY5tujekBS32jfC/7AnH7I0v1v1TbbK3Gp\n XNeiN4QroO+5qaSr0ID2sz5jtBLRb15RMre27E1ImpaIv2Jw8NJgW0k/D1RyKCwaTsgRdwuK\n Kx/Y91XuSBdz0uOyU/S8kM1+ag0wvsGlpBVxRR/xw/E8M7TEwuCZQArqqTCmkG6HGcXFT0V9\n PXFNNgV5jXMQRwU0O/ztJIQqsE5LsUomE//bLwzj9IVsaQpKDqW6TAPjcdBDPLHvriq7kGjt\n WhVhdl0qEYB8lkBEU7V2Yb+SYhmhpDrti9Fq1EsmhiHSkxJcGREoMK/63r9WLZYI3+4W2rAc\n UucZa4OT27U5ZISjNg3Ev0rxU5UH2/pT4wJCfxwocmqaRr6UYmrtZmND89X0KigoFD/XSeVv\n jwBRNjPAubK9/k5NoRrYqztM9W6sJqrH8+UWZ1Idd/DdmogJh0gNC0+N42Za9yBRURfIdKSb\n B3JfpUqcWwE7vUaYrHG1nw54pLUoPG6sAA7Mehl3nd4pZUALHwARAQABzS5EYXZpZCBIaWxk\n ZW5icmFuZCAoQ3VycmVudCkgPGRhdmlkQGtlcm5lbC5vcmc+wsGQBBMBCAA6AhsDBQkmWAik\n AgsJBBUKCQgCFgICHgUCF4AWIQQb2cqtc1xMOkYN/MpN3hD3AP+DWgUCaYJt/AIZAQAKCRBN\n 3hD3AP+DWriiD/9BLGEKG+N8L2AXhikJg6YmXom9ytRwPqDgpHpVg2xdhopoWdMRXjzOrIKD\n g4LSnFaKneQD0hZhoArEeamG5tyo32xoRsPwkbpIzL0OKSZ8G6mVbFGpjmyDLQCAxteXCLXz\n ZI0VbsuJKelYnKcXWOIndOrNRvE5eoOfTt2XfBnAapxMYY2IsV+qaUXlO63GgfIOg8RBaj7x\n 3NxkI3rV0SHhI4GU9K6jCvGghxeS1QX6L/XI9mfAYaIwGy5B68kF26piAVYv/QZDEVIpo3t7\n /fjSpxKT8plJH6rhhR0epy8dWRHk3qT5tk2P85twasdloWtkMZ7FsCJRKWscm1BLpsDn6EQ4\n jeMHECiY9kGKKi8dQpv3FRyo2QApZ49NNDbwcR0ZndK0XFo15iH708H5Qja/8TuXCwnPWAcJ\n DQoNIDFyaxe26Rx3ZwUkRALa3iPcVjE0//TrQ4KnFf+lMBSrS33xDDBfevW9+Dk6IISmDH1R\n HFq2jpkN+FX/PE8eVhV68B2DsAPZ5rUwyCKUXPTJ/irrCCmAAb5Jpv11S7hUSpqtM/6oVESC\n 3z/7CzrVtRODzLtNgV4r5EI+wAv/3PgJLlMwgJM90Fb3CB2IgbxhjvmB1WNdvXACVydx55V7\n LPPKodSTF29rlnQAf9HLgCphuuSrrPn5VQDaYZl4N/7zc2wcWM7BTQRVy5+RARAA59fefSDR\n 9nMGCb9LbMX+TFAoIQo/wgP5XPyzLYakO+94GrgfZjfhdaxPXMsl2+o8jhp/hlIzG56taNdt\n VZtPp3ih1AgbR8rHgXw1xwOpuAd5lE1qNd54ndHuADO9a9A0vPimIes78Hi1/yy+ZEEvRkHk\n /kDa6F3AtTc1m4rbbOk2fiKzzsE9YXweFjQvl9p+AMw6qd/iC4lUk9g0+FQXNdRs+o4o6Qvy\n iOQJfGQ4UcBuOy1IrkJrd8qq5jet1fcM2j4QvsW8CLDWZS1L7kZ5gT5EycMKxUWb8LuRjxzZ\n 3QY1aQH2kkzn6acigU3HLtgFyV1gBNV44ehjgvJpRY2cC8VhanTx0dZ9mj1YKIky5N+C0f21\n zvntBqcxV0+3p8MrxRRcgEtDZNav+xAoT3G0W4SahAaUTWXpsZoOecwtxi74CyneQNPTDjNg\n azHmvpdBVEfj7k3p4dmJp5i0U66Onmf6mMFpArvBRSMOKU9DlAzMi4IvhiNWjKVaIE2Se9BY\n FdKVAJaZq85P2y20ZBd08ILnKcj7XKZkLU5FkoA0udEBvQ0f9QLNyyy3DZMCQWcwRuj1m73D\n sq8DEFBdZ5eEkj1dCyx+t/ga6x2rHyc8Sl86oK1tvAkwBNsfKou3v+jP/l14a7DGBvrmlYjO\n 59o3t6inu6H7pt7OL6u6BQj7DoMAEQEAAcLBfAQYAQgAJgIbDBYhBBvZyq1zXEw6Rg38yk3e\n EPcA/4NaBQJonNqrBQkmWAihAAoJEE3eEPcA/4NaKtMQALAJ8PzprBEXbXcEXwDKQu+P/vts\n IfUb1UNMfMV76BicGa5NCZnJNQASDP/+bFg6O3gx5NbhHHPeaWz/VxlOmYHokHodOvtL0WCC\n 8A5PEP8tOk6029Z+J+xUcMrJClNVFpzVvOpb1lCbhjwAV465Hy+NUSbbUiRxdzNQtLtgZzOV\n Zw7jxUCs4UUZLQTCuBpFgb15bBxYZ/BL9MbzxPxvfUQIPbnzQMcqtpUs21CMK2PdfCh5c4gS\n sDci6D5/ZIBw94UQWmGpM/O1ilGXde2ZzzGYl64glmccD8e87OnEgKnH3FbnJnT4iJchtSvx\n yJNi1+t0+qDti4m88+/9IuPqCKb6Stl+s2dnLtJNrjXBGJtsQG/sRpqsJz5x1/2nPJSRMsx9\n 5YfqbdrJSOFXDzZ8/r82HgQEtUvlSXNaXCa95ez0UkOG7+bDm2b3s0XahBQeLVCH0mw3RAQg\n r7xDAYKIrAwfHHmMTnBQDPJwVqxJjVNr7yBic4yfzVWGCGNE4DnOW0vcIeoyhy9vnIa3w1uZ\n 3iyY2Nsd7JxfKu1PRhCGwXzRw5TlfEsoRI7V9A8isUCoqE2Dzh3FvYHVeX4Us+bRL/oqareJ\n CIFqgYMyvHj7Q06kTKmauOe4Nf0l0qEkIuIzfoLJ3qr5UyXc2hLtWyT9Ir+lYlX9efqh7mOY\n qIws/H2t","In-Reply-To":"","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"7bit","X-Spam-Status":"No, score=-0.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,\n\tDKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}},{"id":3681431,"web_url":"http://patchwork.ozlabs.org/comment/3681431/","msgid":"<139193CD-6D52-4114-82D1-3093B3F3C9E1@linux.dev>","date":"2026-04-23T12:31:04","subject":"Re: [PATCH v5 v5 2/6] mm/memory_hotplug: Fix incorrect altmap passing\n in error path","submitter":{"id":84878,"url":"http://patchwork.ozlabs.org/api/people/84878/","name":"Muchun Song","email":"muchun.song@linux.dev"},"content":"> On Apr 23, 2026, at 20:28, David Hildenbrand (Arm) wrote:\n> \n> On 4/23/26 14:18, Muchun Song wrote:\n>> \n>> \n>>> On Apr 23, 2026, at 18:38, David Hildenbrand (Arm) wrote:\n>>> \n>>> On 4/23/26 09:19, Muchun Song wrote:\n>>>> In create_altmaps_and_memory_blocks(), when arch_add_memory() succeeds\n>>>> with memmap_on_memory enabled, the vmemmap pages are allocated from\n>>>> params.altmap. If create_memory_block_devices() subsequently fails, the\n>>>> error path calls arch_remove_memory() with a NULL altmap instead of\n>>>> params.altmap.\n>>>> \n>>>> This is a bug that could lead to memory corruption. Since altmap is\n>>>> NULL, vmemmap_free() falls back to freeing the vmemmap pages into the\n>>>> system buddy allocator via free_pages() instead of the altmap.\n>>>> arch_remove_memory() then immediately destroys the physical linear\n>>>> mapping for this memory. This injects unowned pages into the buddy\n>>>> allocator, causing machine checks or memory corruption if the system\n>>>> later attempts to allocate and use those freed pages.\n>>>> \n>>>> Fix this by passing params.altmap to arch_remove_memory() in the error\n>>>> path.\n>>>> \n>>>> Fixes: 6b8f0798b85a (\"mm/memory_hotplug: split memmap_on_memory requests across memblocks\")\n>>>> Signed-off-by: Muchun Song \n>>>> ---\n>>>> mm/memory_hotplug.c | 2 +-\n>>>> 1 file changed, 1 insertion(+), 1 deletion(-)\n>>>> \n>>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\n>>>> index 2a943ec57c85..0bad2aed2bde 100644\n>>>> --- a/mm/memory_hotplug.c\n>>>> +++ b/mm/memory_hotplug.c\n>>>> @@ -1468,7 +1468,7 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n>>>> ret = create_memory_block_devices(cur_start, memblock_size, nid,\n>>>> params.altmap, group);\n>>>> if (ret) {\n>>>> - arch_remove_memory(cur_start, memblock_size, NULL);\n>>>> + arch_remove_memory(cur_start, memblock_size, params.altmap);\n>>>> kfree(params.altmap);\n>>>> goto out;\n>>>> }\n>>> \n>>> Yeah, that's nasty. We should CC stable.\n>> \n>> Make sense.\n>> \n>>> \n>>> Acked-by: David Hildenbrand (Arm) \n>> \n>> Thanks.\n>> \n>>> \n>>> \n>>> \n>>> Should we extend the safety checks we already have on the other path?\n>> \n>> Better to have.\n>> \n>>> \n>>> \n>>> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c\n>>> index 2a943ec57c85..1c304468af08 100644\n>>> --- a/mm/memory_hotplug.c\n>>> +++ b/mm/memory_hotplug.c\n>>> @@ -1402,6 +1402,12 @@ bool mhp_supports_memmap_on_memory(void)\n>>> }\n>>> EXPORT_SYMBOL_GPL(mhp_supports_memmap_on_memory);\n>>> \n>>> +static void altmap_free(struct vmemmap_altmap *altmap)\n>>> +{\n>>> + WARN(altmap->alloc, \"Altmap not fully unmapped\");\n>> \n>> Should we change it to WARN_ONCE?\n> \n> Was debating with myself, and yes, I think so.\n> \n>> \n>>> + kfree(altmap);\n>>> +}\n>>> +\n>>> static void remove_memory_blocks_and_altmaps(u64 start, u64 size)\n>>> {\n>>> unsigned long memblock_size = memory_block_size_bytes();\n>>> @@ -1426,10 +1432,7 @@ static void remove_memory_blocks_and_altmaps(u64 start, u64 size)\n>>> remove_memory_block_devices(cur_start, memblock_size);\n>>> \n>>> arch_remove_memory(cur_start, memblock_size, altmap);\n>>> -\n>>> - /* Verify that all vmemmap pages have actually been freed. */\n>>> - WARN(altmap->alloc, \"Altmap not fully unmapped\");\n>>> - kfree(altmap);\n>>> + altmap_free(altmap);\n>>> }\n>>> }\n>>> \n>>> @@ -1460,7 +1463,7 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n>>> /* call arch's memory hotadd */\n>>> ret = arch_add_memory(nid, cur_start, memblock_size, ¶ms);\n>>> if (ret < 0) {\n>>> - kfree(params.altmap);\n>>> + altmap_free(params.altmap);\n>>> goto out;\n>>> }\n>>> \n>>> @@ -1469,13 +1472,12 @@ static int create_altmaps_and_memory_blocks(int nid, struct memory_group *group,\n>>> params.altmap, group);\n>>> if (ret) {\n>>> arch_remove_memory(cur_start, memblock_size, NULL);\n>>> - kfree(params.altmap);\n>>> + altmap_free(params.altmap);\n>>> goto out;\n>>> }\n>>> }\n>>> \n>>> return 0;\n>>> -out:\n>>> if (ret && cur_start != start)\n>>> remove_memory_blocks_and_altmaps(start, cur_start - start);\n>>> return ret;\n>>> \n>>> \n>>> Maybe the helper should even go into altmap code? Not sure.\n>> \n>> I think the current changes look great as they are. While I believe this is valuable\n>> as a standalone cleanup, what do you think?\n> Makes sense. Could you do me the favor and follow up with that, on top of the fixes?\n\nNo problem.\n\n> \n> -- \n> Cheers,\n> \n> David","headers":{"Return-Path":"\n ","X-Original-To":["incoming@patchwork.ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":"patchwork-incoming@legolas.ozlabs.org","Authentication-Results":["legolas.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=l9X21ct7;\n\tdkim-atps=neutral","legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.ozlabs.org\n (client-ip=2404:9400:21b9:f100::1; helo=lists.ozlabs.org;\n envelope-from=linuxppc-dev+bounces-20012-incoming=patchwork.ozlabs.org@lists.ozlabs.org;\n receiver=patchwork.ozlabs.org)","lists.ozlabs.org;\n arc=none smtp.remote-ip=95.215.58.186","lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.dev","lists.ozlabs.org;\n\tdkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=l9X21ct7;\n\tdkim-atps=neutral","lists.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=linux.dev\n (client-ip=95.215.58.186; helo=out-186.mta1.migadu.com;\n envelope-from=muchun.song@linux.dev; receiver=lists.ozlabs.org)"],"Received":["from lists.ozlabs.org (lists.ozlabs.org\n [IPv6:2404:9400:21b9:f100::1])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4g1bBn6Rv1z1yD5\n\tfor ; Thu, 23 Apr 2026 22:34:41 +1000 (AEST)","from boromir.ozlabs.org (localhost [127.0.0.1])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 4g1bBm6sbjz2yGf;\n\tThu, 23 Apr 2026 22:34:40 +1000 (AEST)","from out-186.mta1.migadu.com (out-186.mta1.migadu.com\n [95.215.58.186])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest\n SHA256)\n\t(No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 4g1bBg5VHXz2y8d\n\tfor ; Thu, 23 Apr 2026 22:34:34 +1000 (AEST)"],"ARC-Seal":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707; t=1776947680;\n\tcv=none;\n b=SUIkYa2ELC1gvcF9wKV8QbZ8xelpx5hp1/Q6HLKnkr3jgMs3FezilFSDI1TzTpxyKFI/EFjmkI1THwK3crtlYjOmhywpDjauGBEUbNyF0BtOlEboLW4wsNNDEqBq0TYHsavK9KvokuBy4as7bDxYpwM4bJMR6lxDMZCA7SMksKBiTvXJsUa/u7kdkA6pmYfwgY0JE4J+F3hooI4MYR1a+kyzeTd0uiDLz0bFXqn/ApeVu33riYkNBaOWbZTAUGCkvhduUljtGXxEJh/BTNbsUr6fCzsXli0+S4Rj3+CA+squlVMzRkeui9ufGnhbL4UefnFIyedD0mDM2bp3VBStkA==","ARC-Message-Signature":"i=1; a=rsa-sha256; d=lists.ozlabs.org; s=201707;\n\tt=1776947680; c=relaxed/relaxed;\n\tbh=Lw49zwURroj4cNnSa8wLXSWhI5yryxe8VvIKls8yX7s=;\n\th=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:\n\t Message-Id:References:To;\n b=KZqhaENtIFQZttBE5lyU6PokcGNd+Edo9preuCwFueYMiL/n7nJcjzsCbyUyAOkSf8dac90siX0ZeutWdaKDMWixcbyEGuBA7TTPYof0BUiPM9qDig9Is/tcLNo0psMpkUeAA2GBbUhyULNgeUPHsG13BnqVzggisiyTqsYsHGs84E9lesBH3nDHiAKfh7iVjeNW8jJ5Dcy0D3/hw+hqL/Llt/QPOMX5dq6efER0uVEi7TrkJSvYcvHq1J01a7ZO9Ol/SuGAQQQZGkFg84wrdZhi+vTHGPzeJ6Rqfpw9XOhF1Ek9m1UWjke8IhfcZKNm6T8aLhzoPoAuxb1pmr0i2w==","ARC-Authentication-Results":"i=1; lists.ozlabs.org;\n dmarc=pass (p=none dis=none) header.from=linux.dev; dkim=pass (1024-bit key;\n unprotected) header.d=linux.dev header.i=@linux.dev header.a=rsa-sha256\n header.s=key1 header.b=l9X21ct7; dkim-atps=neutral;\n spf=pass (client-ip=95.215.58.186; helo=out-186.mta1.migadu.com;\n envelope-from=muchun.song@linux.dev;\n receiver=lists.ozlabs.org) smtp.mailfrom=linux.dev","Content-Type":"text/plain;\n\tcharset=us-ascii","DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1;\n\tt=1776947654;\n\th=from:from:reply-to:subject:subject:date:date:message-id:message-id:\n\t to:to:cc:cc:mime-version:mime-version:content-type:content-type:\n\t content-transfer-encoding:content-transfer-encoding:\n\t in-reply-to:in-reply-to:references:references;\n\tbh=Lw49zwURroj4cNnSa8wLXSWhI5yryxe8VvIKls8yX7s=;\n\tb=l9X21ct7waizi915h79BbuDuGau1Z93SKDUm3rxRMbrJGUAaqEMlOwYvImdQpDAywOkq1b\n\t7DS686VPF0wKsgRwF0xtHtANLNQFUVR9ubGe9ZJSbHxez84vmZtSE+OmDO2IWJNQqbhnYY\n\tDFRh+2d9ph8oyKsM7CW1J63XOari2lw=","X-Mailing-List":"linuxppc-dev@lists.ozlabs.org","List-Id":"","List-Help":"","List-Owner":"","List-Post":"","List-Archive":",\n ","List-Subscribe":",\n ,\n ","List-Unsubscribe":"","Precedence":"list","Mime-Version":"1.0 (Mac OS X Mail 16.0 \\(3864.500.181\\))","Subject":"Re: [PATCH v5 v5 2/6] mm/memory_hotplug: Fix incorrect altmap passing\n in error path","X-Report-Abuse":"Please report any abuse attempt to abuse@migadu.com and\n include these headers.","From":"Muchun Song ","In-Reply-To":"<25aac60c-8510-4d92-85f3-368cfe9d83ef@kernel.org>","Date":"Thu, 23 Apr 2026 20:31:04 +0800","Cc":"Muchun Song ,\n Andrew Morton ,\n Oscar Salvador ,\n Michael Ellerman ,\n Madhavan Srinivasan ,\n Lorenzo Stoakes ,\n \"Liam R . Howlett\" ,\n Vlastimil Babka ,\n Mike Rapoport ,\n Suren Baghdasaryan ,\n Michal Hocko ,\n Nicholas Piggin ,\n Christophe Leroy ,\n aneesh.kumar@linux.ibm.com,\n joao.m.martins@oracle.com,\n linux-mm@kvack.org,\n linuxppc-dev@lists.ozlabs.org,\n linux-kernel@vger.kernel.org","Content-Transfer-Encoding":"quoted-printable","Message-Id":"<139193CD-6D52-4114-82D1-3093B3F3C9E1@linux.dev>","References":"<20260423071911.1962859-1-songmuchun@bytedance.com>\n <20260423071911.1962859-3-songmuchun@bytedance.com>\n \n \n <25aac60c-8510-4d92-85f3-368cfe9d83ef@kernel.org>","To":"\"David Hildenbrand (Arm)\" ","X-Migadu-Flow":"FLOW_OUT","X-Spam-Status":"No, score=-0.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID,\n\tDKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS\n\tautolearn=disabled version=4.0.1 OzLabs 8","X-Spam-Checker-Version":"SpamAssassin 4.0.1 (2024-03-25) on lists.ozlabs.org"}}]