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 7BE501DB356 for ; Fri, 26 Jun 2026 00:46:21 +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=1782434782; cv=none; b=WDJTrwEA81bOa8W54a+LxFK0ylSfs0MIUH9y3+XYZqTNUqzsneQ6Nh87T5s4WFo1D1uvadHiEjBSKAR3dTsrdbKQmyMGwTRGTWeYPee+Ivw4HNObfNPs/JGpKLKZNlS96WYrUunN4ctAFIHVVtY6Z4azrDc8ceqDZMcCa/aHjPE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782434782; c=relaxed/simple; bh=QUbKgQtU0sTrZlnbRE3i7FuDW942+6GHi1Czyc4hn6s=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=Y+Aqi9wNbmtra7c3cIrVkbRIWPLGbj2rdITN1PRDSFRM7IXX/VOwx1xRMuvMmaa9iL/qUBh9QsionhOd4I2noYsOMTVOI4LR/eFV+g2gimmnELvGQC51CJdAw+zJuV9JPPLknyhxbL2EenF5pbiEH/phqxD8/90ZPrSpfSNHASo= 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=ttuUkkW9; 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="ttuUkkW9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 903801F000E9; Fri, 26 Jun 2026 00:46:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1782434781; bh=aVwnJDGi7HOXHyeM0jNjwmLxXliLE7L625+/NqaYxmg=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ttuUkkW9XB6RuZTLYjeJ/3uTYeXRf6yq0egZXdrkILgAmZizyGc15vX5NyM2XHWzD tb2k1YiKgsHTU9XgApnhlqlUXzoIYDtrltk0/8s1pLM+JAaHAVeY8PIo2wZL+iaNvF qR60k0TTyAaXwmuUmEv88320MeMUOpwVNwW8AI7A= Date: Thu, 25 Jun 2026 17:46:19 -0700 From: Andrew Morton To: Muchun Song Cc: Oscar Salvador , David Hildenbrand , Madhavan Srinivasan , Michael Ellerman , Muchun Song , Mike Rapoport , Lorenzo Stoakes , "Liam R . Howlett" , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Nicholas Piggin , Christophe Leroy , Ritesh Harjani , "Aneesh Kumar K . V" , linuxppc-dev@lists.ozlabs.org, Mike Kravetz , Michal Clapinski ? Subject: Re: [PATCH v4 00/19] mm: Refactor bootmem gigantic hugepage allocation Message-Id: <20260625174619.45d7b772b69b7b54b7f3bae1@linux-foundation.org> In-Reply-To: <20260612035903.2468601-1-songmuchun@bytedance.com> References: <20260612035903.2468601-1-songmuchun@bytedance.com> 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, 12 Jun 2026 11:58:44 +0800 Muchun Song wrote: > This series is split out from the earlier larger series "mm: Generalize > HVO for HugeTLB and device DAX" [1]. It collects the first 19 patches of > that series as a standalone set of fixes and preparatory cleanups around > bootmem HugeTLB handling, sparse initialization ordering, and related > vmemmap setup. > > The first patches fix a few bugs found while reviewing the existing > code, including incorrect bootmem HVO handling, wrong vmemmap > registration arguments, a powerpc compound-vmemmap tracking bug, and > too-late initialization of gigantic bootmem HugeTLB struct pages. > > The rest of the series reorders early memory initialization so the > relevant zone state is available before sparse and HugeTLB boot-time > setup runs, then simplifies the remaining bootmem gigantic hugepage > allocation path and removes code made obsolete by that rework. Thanks, I added this to mm.git's mm-new branch. As requested, I dropped Michal's "mm/hugetlb: init tails before init_migratetype" from the mm-hotfixes-unstable branch. Michal, can you please review and perhaps test [01/19] "mm/hugetlb: fix boot panic with CONFIG_DEBUG_VM and HVO bootmem pages" (https://lore.kernel.org/20260612035903.2468601-2-songmuchun@bytedance.com)? Thanks. I added cc:stable to [01/19], as CONFIG_DEBUG_VM is not uncommon. I added this series as-sent. This means that the four cc:stable patches won't be offered to -stable maintainers for 2+ months. If you feel that some/all of them should be upstreamed earlier than this, please let me know and I'll make the necessary reorganizations. And thanks for checking the Sashiko report. Dang thing ;)