From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DA10E1A6830; Fri, 22 May 2026 00:35:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779410152; cv=none; b=lopw6qtafISX/ZLzXTCMzAa+SuT30ULETNQySjmkPCeOosZYpJsJ15pSA325RH7v18qJYQ4b7v7YFuQlaN8j/28k2lgSDM1xDwFC9QODyYRFvzsqd9uE1LVtr47Oc64bc0+0cglXsTFZRERZIOa5sX7TYtqx7IeETPZrTFNxRk8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779410152; c=relaxed/simple; bh=AD9aedaG6MP6W9sNDJYHBG1IbeFXeavDmpWvGiggHzE=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=aug46d1Vd221JdMBtN4iOmSAUh7IktNK9DtWubYNGC1ClPNjGSZ+Az617gKdX7giGqY8zGbwRxSnm3k3gYOjYnc7X4HGLTEpQKm073YdK4hsQRIV3mQZryuuSwILVnUT9oAzR/n88fkslElnyn/OK9vojrpKEvLJX9rl+32StFM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=NdIPAQ7w; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="NdIPAQ7w" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0714C1F000E9; Fri, 22 May 2026 00:35:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1779410150; bh=yljY8YQyXmVtcHk2rKuFniU/EGNik4faj4r2Y5gPpNE=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=NdIPAQ7wkTRT8DsRoisNUDzR0BsNKEEoUpDrQYPem0wQskvvSQQN6y+EEHdjh+w5p RTyTwMbZWwUA/FIlWMPQvS4gcbIV8a3CpDPkRWPTV342je1rucse2JApFOeRssfP3/ IOWujqDHkDEXnezGBWbRuDWc/a61l6X6xW4hxIG0= Date: Thu, 21 May 2026 17:35:49 -0700 From: Andrew Morton To: "David Hildenbrand (Arm)" Cc: Peter Zijlstra , Dave Hansen , Andy Lutomirski , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , "Mike Rapoport (Microsoft)" , Jason Gunthorpe , Lu Baolu , Lance Yang , linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [PATCH v2] x86/mm: fix freeing of PMD-sized vmemmap pages Message-Id: <20260521173549.d5aa510a710b4d77c3f7afeb@linux-foundation.org> In-Reply-To: <32fc4c35-acdb-4202-8369-ac0fe00c5b86@kernel.org> References: <20260429-vmemmap-v2-1-8dfcacffd877@kernel.org> <0c20d1e6-1a39-42c5-8c94-9bd2222fb6b3@kernel.org> <20260508092341.GP3126523@noisy.programming.kicks-ass.net> <32fc4c35-acdb-4202-8369-ac0fe00c5b86@kernel.org> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 8 May 2026 12:51:31 +0200 "David Hildenbrand (Arm)" wrote: > >>> Tested-by: Lance Yang > >>> Acked-by: Mike Rapoport (Microsoft) > >>> Fixes: bf9e4e30f353 ("x86/mm: use pagetable_free()") > >>> Cc: stable@vger.kernel.org > >>> Signed-off-by: David Hildenbrand (Arm) > >>> --- > >>> Reproduced and tested with a simple VM with a virtio-mem device, > >>> repeatedly adding and removing memory. > >>> > >>> Found by code inspection while working on bootmem_info removal. > >>> --- > >> > >> @x86 maintainers, do you want to take this through your tree or should we merge > >> this through the MM tree? > >> > >> I have another MM series coming up that will touch this code (no fixes, though). > > > > I'm thinking this should go in rather more urgent, yes? > > Yes, please :) I'm not seeing this in linux-next so I (re) queued it in mm.git's mm-hotfixes-unstble queue, for a 7.1-rcX merge. From: "David Hildenbrand (Arm)" Subject: x86/mm: fix freeing of PMD-sized vmemmap pages Date: Wed, 29 Apr 2026 12:49:14 +0200 In commit bf9e4e30f353 ("x86/mm: use pagetable_free()"), we switched from freeing non-boot page tables through __free_pages() to pagetable_free(). However, the function is also called to free vmemmap pages. Given that vmemmap pages are not page tables, already the page_ptdesc(page) is wrong. But worse, pagetable_free() calls __free_pages(page, compound_order(page)); As vmemmap pages are not compound pages (see vmemmap_alloc_block()) -- except for HVO, which doesn't apply here -- we will only free the first page when freeing a PMD-sized vmemmap page, leaking the other ones. Fix it by properly decoupling pagetable and vmemmap freeing. free_pagetable() no longer has to mess with SECTION_INFO, as only the vmemmap is marked like that in register_page_bootmem_memmap(). The indentation in remove_pmd_table() is messed up, let's fix that while touching it. Note that we'll try to get rid of that bootmem info handling soon. For now, we'll handle it similar to free_pagetable(), just avoiding the ifdef. Link: https://lore.kernel.org/20260429-vmemmap-v2-1-8dfcacffd877@kernel.org Fixes: bf9e4e30f353 ("x86/mm: use pagetable_free()") Signed-off-by: David Hildenbrand (Arm) Tested-by: Lance Yang Acked-by: Mike Rapoport (Microsoft) Cc: Dave Hansen Cc: Andy Lutomirski Cc: Baolu Lu Cc: "Borislav Petkov (AMD)" Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: Jason Gunthorpe Cc: Peter Zijlstra Cc: Signed-off-by: Andrew Morton --- arch/x86/mm/init_64.c | 40 ++++++++++++++++++++++++++-------------- 1 file changed, 26 insertions(+), 14 deletions(-) --- a/arch/x86/mm/init_64.c~x86-mm-fix-freeing-of-pmd-sized-vmemmap-pages +++ a/arch/x86/mm/init_64.c @@ -1014,7 +1014,7 @@ static void __meminit free_pagetable(str #ifdef CONFIG_HAVE_BOOTMEM_INFO_NODE enum bootmem_type type = bootmem_type(page); - if (type == SECTION_INFO || type == MIX_SECTION_INFO) { + if (type == MIX_SECTION_INFO) { while (nr_pages--) put_page_bootmem(page++); } else { @@ -1028,13 +1028,24 @@ static void __meminit free_pagetable(str } } -static void __meminit free_hugepage_table(struct page *page, +static void __meminit free_vmemmap_pages(struct page *page, unsigned int order, struct vmem_altmap *altmap) { - if (altmap) - vmem_altmap_free(altmap, PMD_SIZE / PAGE_SIZE); - else - free_pagetable(page, get_order(PMD_SIZE)); + unsigned long nr_pages = 1u << order; + + if (altmap) { + vmem_altmap_free(altmap, nr_pages); + } else if (PageReserved(page)) { + if (IS_ENABLED(CONFIG_HAVE_BOOTMEM_INFO_NODE) && + bootmem_type(page) == SECTION_INFO) { + while (nr_pages--) + put_page_bootmem(page++); + } else { + free_reserved_pages(page, nr_pages); + } + } else { + __free_pages(page, order); + } } static void __meminit free_pte_table(pte_t *pte_start, pmd_t *pmd) @@ -1118,7 +1129,8 @@ remove_pte_table(pte_t *pte_start, unsig return; if (!direct) - free_pagetable(pte_page(*pte), 0); + /* We never populate base pages from the altmap. */ + free_vmemmap_pages(pte_page(*pte), 0, NULL); spin_lock(&init_mm.page_table_lock); pte_clear(&init_mm, addr, pte); @@ -1153,19 +1165,19 @@ remove_pmd_table(pmd_t *pmd_start, unsig if (IS_ALIGNED(addr, PMD_SIZE) && IS_ALIGNED(next, PMD_SIZE)) { if (!direct) - free_hugepage_table(pmd_page(*pmd), - altmap); + free_vmemmap_pages(pmd_page(*pmd), + PMD_ORDER, altmap); spin_lock(&init_mm.page_table_lock); pmd_clear(pmd); spin_unlock(&init_mm.page_table_lock); pages++; } else if (vmemmap_pmd_is_unused(addr, next)) { - free_hugepage_table(pmd_page(*pmd), - altmap); - spin_lock(&init_mm.page_table_lock); - pmd_clear(pmd); - spin_unlock(&init_mm.page_table_lock); + free_vmemmap_pages(pmd_page(*pmd), PMD_ORDER, + altmap); + spin_lock(&init_mm.page_table_lock); + pmd_clear(pmd); + spin_unlock(&init_mm.page_table_lock); } continue; } _