From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f202.google.com (mail-pl1-f202.google.com [209.85.214.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 009823264DE for ; Sun, 31 May 2026 05:58:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.202 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780207115; cv=none; b=jzhJNY6/CxSgzEXWRhbiSHt8nV3mpLlom4FVBQDFFTwDkd96DYId71S/fD/FZv89cnKqwFXUyaQrGJwa3F2Y9ExsW/qA6Hgm+zRP2CvvrcW4LW1KQw9Cy40K1/eMZJFobycQgHcYOsY9Qovcw68b9+ZJyEVEwRVMeV2BMzo3N+0= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780207115; c=relaxed/simple; bh=oJTbJ4rC3HckIGNYnW+CgN8+OfWbnuHbTistF1Nq/zs=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=b5LjrzJEmxGQuQM5ysGPnFax4cPloxUBboAoI8juEn1cXwJ3YAQiqb4BNekkUBsiBwEHI/jabtqvejPq+sCen5dMtbh6jZefj81sf30IljTCpyJbSVa5SZLx6MPl3URDzDZY04HAGkVmWqbVBQAOPyiSWmS8RnJlL+RhgsMQIiU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--jiaqiyan.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=aGFpMVGG; arc=none smtp.client-ip=209.85.214.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--jiaqiyan.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="aGFpMVGG" Received: by mail-pl1-f202.google.com with SMTP id d9443c01a7336-2bf0b7425bbso56164875ad.0 for ; Sat, 30 May 2026 22:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780207113; x=1780811913; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=snShNS8B0A/roLa9I0WH5+4cW+eeLsBmpxsgxamM+Gw=; b=aGFpMVGGfFXQC609VFlyGu2dsB18l6+uNgaMgfG83UvmrqzXHZk8HNe+1v22csIxTh e6zBkwEFk67m4euNNS0y3soXuUpPA7e1iqStgsIAgzd4HstQOgItpj4jOd72/aHuolYH TwxNjVL/8HT02LIF1UYQ5g4hZIuYKY1pVFU6wCHrs2eSUSD2uSsjA1cVBwEyi5YZoyH0 JBXWAIQTp+qp6VTXyAnmkwFD07EpFYUonUMJG+F3/FrkQMgOll9iXlG64abt88mgMfPn 7auUjLJ9qUlfDYSMMzUfIn+TItE3oZk05Eymswrc9B05TQ145lXn8jYA3OvTmN8t9GR4 FneA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780207113; x=1780811913; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=snShNS8B0A/roLa9I0WH5+4cW+eeLsBmpxsgxamM+Gw=; b=ap/hglfpvTK2KjelBmpyu/mNTMwjXNm29/ktPFYUzn9FdL2F1H7TY8hxj4bXP+Hz4/ KeXUjHHZnQ39Cn5vXYcACUEXInr0kKQ/LbSe87P/rPxQb7POpUg121OE4PhJ7E+8CXYf 3RWO2Cpz0qOKXNWM2EmebooPXy/uda8EK+d6+E8oO8qSLBYhW9fikP4XC9YrqI+sjAiR cnK1sbGUtmNdEYD22BFzFX6/PsNpQij/oBCirZ6APeIqlnn1E43+KbbBuqCxJAmfCq0o 5gJLVoBVsqU/X1A6J3iLZSzzDVyTyZx/RKAkrfugF3al5uUT14VDJ4V3DooC3byrdW/c u0aw== X-Forwarded-Encrypted: i=1; AFNElJ9Qq8jcXqM70/Y8S9KBh2q6MnFV0no8EJGLUncWm2VktyPft/aep4irADoxe7qK612An0vABwL6hq1elzI=@vger.kernel.org X-Gm-Message-State: AOJu0YxVe/WfP4oKgNQmlOXv0Yv5dTxjt5lztyOE3Ap6XEa09TP2GW7D 11NnA/nVFKjn95pSOmKc6i4d0o6hlDt1meucThoW4aHK8gtgtzBczaUiI1l0k56J7jxFVyJa74F J7We8eq3kxBgRnQ== X-Received: from plcp19.prod.google.com ([2002:a17:902:e353:b0:2bd:7a0a:2d41]) (user=jiaqiyan job=prod-delivery.src-stubby-dispatcher) by 2002:a17:902:e88e:b0:2c0:a3dd:4e6c with SMTP id d9443c01a7336-2c0a3dd4f17mr55603535ad.38.1780207113137; Sat, 30 May 2026 22:58:33 -0700 (PDT) Date: Sun, 31 May 2026 05:58:26 +0000 In-Reply-To: <20260531055829.3636554-1-jiaqiyan@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260531055829.3636554-1-jiaqiyan@google.com> X-Mailer: git-send-email 2.54.0.823.g6e5bcc1fc9-goog Message-ID: <20260531055829.3636554-2-jiaqiyan@google.com> Subject: [PATCH v5 1/4] mm/page_alloc: only free healthy pages in high-order has_hwpoisoned folio From: Jiaqi Yan To: ljs@kernel.org, linmiaohe@huawei.com, osalvador@kernel.org, ziy@nvidia.com, harry.yoo@oracle.com, willy@infradead.org Cc: osalvador@suse.de, lorenzo.stoakes@oracle.com, jackmanb@google.com, hannes@cmpxchg.org, nao.horiguchi@gmail.com, david@kernel.org, william.roche@oracle.com, tony.luck@intel.com, wangkefeng.wang@huawei.com, jane.chu@oracle.com, akpm@linux-foundation.org, muchun.song@linux.dev, liam@infradead.org, rientjes@google.com, duenwen@google.com, jthoughton@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, vbabka@suse.cz, rppt@kernel.org, shuah@kernel.org, surenb@google.com, mhocko@suse.com, boudewijn@delta-utec.com, Jiaqi Yan Content-Type: text/plain; charset="UTF-8" At the end of dissolve_free_hugetlb_folio(), a free HugeTLB folio becomes non-HugeTLB, and it is released to buddy allocator as a high-order folio, e.g. a folio that contains 262144 pages if the folio was a 1G HugeTLB hugepage. This is problematic if the HugeTLB hugepage contained HWPoison subpages. In that case, since buddy allocator does not check HWPoison for non-zero-order folio, the raw HWPoison page can be given out with its buddy page and be re-used by either kernel or userspace. Memory failure recovery (MFR) in kernel does attempt to take raw HWPoison page off buddy allocator after dissolve_free_hugetlb_folio(). However, there is always a time window between dissolve_free_hugetlb_folio() frees a HWPoison high-order folio to buddy allocator and MFR takes HWPoison raw page off buddy allocator. Another similar situation is when a transparent huge page (THP) runs into memory failure but splitting failed. Such THP will eventually be released to buddy allocator when owning userspace processes are gone, but with certain subpages having HWPoison. One obvious way to avoid both problems is to add page sanity checks in page allocate or free path. However, it is against the past efforts to reduce sanity check overhead [1,2,3]. Introduce free_has_hwpoisoned() to only free the healthy pages and to exclude the HWPoison ones in the high-order folio. The idea is to iterate through the sub-pages of the folio to identify contiguous ranges of healthy pages. free_has_hwpoisoned() is added in free_pages_prepare() as a shortcut and is only invoked if PG_has_hwpoisoned indicates HWPoison page exists and after checks and preparations in free_pages_prepare() all succeeded. free_has_hwpoisoned() then can re-use free_prepared_contig_range() [4] to decompose healthy ranges into the largest possible chunks of different orders. Every chunk meets the requirements to be freed via free_one_page(). free_has_hwpoisoned() has linear time complexity wrt the number of pages in the folio. While the power-of-two decomposition ensures that the number of calls to the buddy allocator is logarithmic for each contiguous healthy range, the mandatory linear scan of pages to identify PageHWPoison() defines the overall time complexity. For a 1G hugepage having 8 HWPoison pages, free_has_hwpoisoned() takes around 1ms on average on a system having 56 Intel Skylake physical cores. This is 15x to the case of freeing no HWPoison page. The cost is far from triggering soft lockup, and fair for handling exceptional hardware memory errors. [1] https://lore.kernel.org/linux-mm/1460711275-1130-15-git-send-email-mgorman@techsingularity.net [2] https://lore.kernel.org/linux-mm/1460711275-1130-16-git-send-email-mgorman@techsingularity.net [3] https://lore.kernel.org/all/20230216095131.17336-1-vbabka@suse.cz [4] https://lore.kernel.org/all/20260401101634.2868165-2-usama.anjum@arm.com Signed-off-by: Jiaqi Yan --- mm/page_alloc.c | 85 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 85 insertions(+) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index e47679e7a9db..03df929abca6 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -208,6 +208,7 @@ gfp_t gfp_allowed_mask __read_mostly = GFP_BOOT_MASK; unsigned int pageblock_order __read_mostly; #endif +static void free_has_hwpoisoned(struct page *page, unsigned int order); static void __free_pages_ok(struct page *page, unsigned int order, fpi_t fpi_flags); static void reserve_highatomic_pageblock(struct page *page, int order, @@ -1309,6 +1310,14 @@ static inline void pgalloc_tag_sub_pages(struct alloc_tag *tag, unsigned int nr) #endif /* CONFIG_MEM_ALLOC_PROFILING */ +/* + * Returns + * - true: checks and preparations all good, caller can proceed freeing. + * - false: do not proceed freeing for one of the following reasons: + * 1. Some check failed so it is not safe to proceed freeing. + * 2. A compound page has some HWPoison pages. The healthy pages + * are already safely freed, and the HWPoison ones isolated. + */ static __always_inline bool __free_pages_prepare(struct page *page, unsigned int order, fpi_t fpi_flags) { @@ -1317,6 +1326,15 @@ static __always_inline bool __free_pages_prepare(struct page *page, bool init = want_init_on_free(); bool compound = PageCompound(page); struct folio *folio = page_folio(page); + /* + * When dealing with compound page, PG_has_hwpoisoned is cleared + * with PAGE_FLAGS_SECOND. So the check must be done first. + * + * Note we can't exclude PG_has_hwpoisoned from PAGE_FLAGS_SECOND. + * Because PG_has_hwpoisoned == PG_active, free_page_is_bad() will + * confuse and complaint that the first tail page is still active. + */ + bool should_fhh = compound && folio_test_has_hwpoisoned(folio); if (fpi_flags & FPI_PREPARED) return true; @@ -1443,6 +1461,16 @@ static __always_inline bool __free_pages_prepare(struct page *page, debug_pagealloc_unmap_pages(page, 1 << order); + /* + * After breaking down compound page and dealing with page metadata + * (e.g. page owner and page alloc tags), take a shortcut if this + * was a compound page containing certain HWPoison subpages. + */ + if (should_fhh) { + free_has_hwpoisoned(page, order); + return false; + } + return true; } @@ -6936,6 +6964,63 @@ void __free_contig_range(unsigned long pfn, unsigned long nr_pages) __free_contig_range_common(pfn, nr_pages, /* is_frozen= */ false); } +/* + * Given a high-order compound page containing certain number of HWPoison + * pages, free only the healthy ones. + * + * Pages must have passed free_pages_prepare(). Even if having HWPoison + * pages, breaking down compound page and updating metadata (e.g. page + * owner, alloc tag) can be done together during free_pages_prepare(), + * which simplifies the splitting here: unlike __split_unmapped_folio(), + * there is no need to turn split pages into a compound page or to carry + * metadata. + * + * It scans every raw page of the compound page and cause nontrivial overhead. + * So only use this when the compound page contains HWPoison page(s). + * + * This implementation needs rework in memdesc world. + */ +static void free_has_hwpoisoned(struct page *page, unsigned int order) +{ + unsigned long curr = page_to_pfn(page); + unsigned long end_pfn = curr + (1 << order); + unsigned long next; + unsigned long total_freed = 0; + unsigned long total_hwp = 0; + + VM_WARN_ON(order == 0); + VM_WARN_ON(page->flags.f & PAGE_FLAGS_CHECK_AT_PREP); + + while (curr < end_pfn) { + next = curr; + + while (next < end_pfn && !PageHWPoison(pfn_to_page(next))) + ++next; + + if (next != end_pfn && PageHWPoison(pfn_to_page(next))) { + /* + * Avoid accounting error when the page is freed + * by unpoison_memory(). + */ + clear_page_tag_ref(pfn_to_page(next)); + ++total_hwp; + } + + free_prepared_contig_range(pfn_to_page(curr), next - curr); + total_freed += next - curr; + + if (next == end_pfn) + break; + + VM_WARN_ON(!PageHWPoison(pfn_to_page(next))); + curr = next + 1; + } + + VM_WARN_ON(total_freed + total_hwp != (1 << order)); + pr_info("Freed %#lx pages, excluded %lu HWPoison pages\n", + total_freed, total_hwp); +} + #ifdef CONFIG_CONTIG_ALLOC /* Usage: See admin-guide/dynamic-debug-howto.rst */ static void alloc_contig_dump_pages(struct list_head *page_list) -- 2.54.0.823.g6e5bcc1fc9-goog