From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f73.google.com (mail-pj1-f73.google.com [209.85.216.73]) (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 6C4AF18D658 for ; Fri, 19 Dec 2025 18:33:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.73 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766169239; cv=none; b=GiYaiT5i0fHR2apgA3K9vOl4MMEBNT3eXlp8no/Yt4uIEq6Z70MwycHfrNDRjLBf431wOHyrUnMIgmQaAfzhvGMzcI5EiUAJCHUwxOmjYUL+sP2eB5dsYjdZL8wC6IYCV73TG00lPwMMUwYOfiod+7+OzYbbvTXA5lSohIcf8PE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1766169239; c=relaxed/simple; bh=ll52+n0KaICRZYG2n190n+Bi4UfUa9o6bk4v9cY/lnU=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=R4QxCmSwgN0NAy1H8aj2EHhM7qkrLUdtfsZ/uK/UQ3LMRFP6BLLC7TNCW1Ru5ZXe45ClujoxdsCaeaZJ5bHKNf4gYYxC/PmiYGYhnexpg0n/dqheSs0zK4VJB649OLd0BDUhD5/ir5eM/GNk0JOw/hWPFo4bYim57DdZ0rsd8a8= 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=ZeWVlBYH; arc=none smtp.client-ip=209.85.216.73 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="ZeWVlBYH" Received: by mail-pj1-f73.google.com with SMTP id 98e67ed59e1d1-34c64cd48a8so4592879a91.0 for ; Fri, 19 Dec 2025 10:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1766169238; x=1766774038; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=lSNGnEFxOyI19g6eLd2Gx6lTfoT3c263QtqCA7O/6yo=; b=ZeWVlBYHe6N6H10i+DTnn8YPviueI9Lmyu8PpHQZtyp8qlAbhbzqXwZTUPycyE+eAu vCxs8aOodFDjb2NSdtVkFKwtYW4Fkd8/l2WsxzFRRRK4OMHvk2pk107b5++SU8GBlYwm rQvk2FsU91phUOUd58cyyx9u9tqCBFmc2S1YLFr3v2fUCXNvBRDVsmH/E3+VBadHt1Nm w6V13j3+fm/vsgKosOGfZodxXLU9NE1hVazyp7WWGGpfXo10QJhzG9uKYsU4NfJpDZ4n z3Jv5Hr7WrUqJRXB9jyJJ1ha+/5ouJ9ElgMtDCh0C+288gn0tfQmbw7KjIKUqQkllcF1 ViKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1766169238; x=1766774038; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=lSNGnEFxOyI19g6eLd2Gx6lTfoT3c263QtqCA7O/6yo=; b=tYitLTCF76tB8MQGJ3hIJJrkV/qSmB9DrJRGhDmhIkKyr8XqUCaNI3EXx7TpzupOOP GUcIu/vXWFRiyWJWES9jmTX5SvB4vvOUeJoa/iRlPHsJHNB06kOgc5zDCQkTLSyyvSQZ 8fQg7k/7RWqnBzocDNn+9+sNY3bSr0W9xoWD2/lmivZnLhDkBQrimBF5W2m6UWenDyk2 h1hoCxfsd1YB+3jqPv14UW8BgbzGP5oe6GFPfddG94Zr9mtLhjzy6FUd45iUsdxGxA4I pxf9q7gAwUHmpwJdYQ9GV2KunIz+vOH3vsf4iWFAx/4bXzCLPdGAffhdeN1iPAGYxvQm cUWQ== X-Forwarded-Encrypted: i=1; AJvYcCVdUi+35kzgA4ozH0x3SaPP+eqP5Eyfbnm6hcLhLYir2NiGTJMrlTKQb0LXWzdRo6emN6+BSljzrigIyc0=@vger.kernel.org X-Gm-Message-State: AOJu0YxVMxZ24bnwjsqkrU9HRgDi9d3PTCcLQMjzBPKG9gGrWC2TQR1I rMDoS1cdVoEryzmvCxvTyXpBAUQhqGpAo5gFIvAbeKLJdX3JRef4W5vDsG2KroYJQM6ahbpYvf1 NKZuVi2EniAhVPw== X-Google-Smtp-Source: AGHT+IHlWbEQHHyZMRyN1CJ6TsZ1t3MpWoqaJTHXvpmESrp3COpy16aFWt0kD4JLtuxjkJkbgfBPzAd+vxBxzA== X-Received: from pjbsj11.prod.google.com ([2002:a17:90b:2d8b:b0:34c:36b0:4e39]) (user=jiaqiyan job=prod-delivery.src-stubby-dispatcher) by 2002:a17:90b:2e0c:b0:341:8bda:d0ae with SMTP id 98e67ed59e1d1-34e921b7334mr2826873a91.20.1766169237687; Fri, 19 Dec 2025 10:33:57 -0800 (PST) Date: Fri, 19 Dec 2025 18:33:43 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Mailer: git-send-email 2.52.0.322.g1dd061c0dc-goog Message-ID: <20251219183346.3627510-1-jiaqiyan@google.com> Subject: [PATCH v2 0/3] Only free healthy pages in high-order HWPoison folio From: Jiaqi Yan To: jackmanb@google.com, hannes@cmpxchg.org, linmiaohe@huawei.com, ziy@nvidia.com, harry.yoo@oracle.com, willy@infradead.org Cc: nao.horiguchi@gmail.com, david@redhat.com, lorenzo.stoakes@oracle.com, william.roche@oracle.com, tony.luck@intel.com, wangkefeng.wang@huawei.com, jane.chu@oracle.com, akpm@linux-foundation.org, osalvador@suse.de, muchun.song@linux.dev, rientjes@google.com, duenwen@google.com, jthoughton@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, Jiaqi Yan Content-Type: text/plain; charset="UTF-8" At the end of dissolve_free_hugetlb_folio that a free HugeTLB folio becomes non-HugeTLB, 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. One obvious way to avoid this problem 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_hwpoison_pages to only free the healthy pages and excludes 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. Instead of freeing pages one by one, decompose healthy ranges into the largest possible blocks. Each block meets the requirements to be freed to buddy allocator by calling __free_frozen_pages directly. free_has_hwpoison_pages has linear time complexity O(N) 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. I tested with some test-only code [4] and hugetlb-mfr [5], by checking the status of pcplist and freelist immediately after dissolve_free_hugetlb_folio a free hugetlb page that contains 3 HWPoison raw pages: * HWPoison pages are excluded by free_has_hwpoison_pages. * Some healthy pages can be in zone->per_cpu_pageset (pcplist) because pcp_count is not high enough. * Many healthy pages are already in some order's zone->free_area[order].free_list (freelist). * In rare cases, some healthy pages are in neither pcplist nor freelist. My best guest is they are allocated before the test checks. [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://drive.google.com/file/d/1CzJn1Cc4wCCm183Y77h244fyZIkTLzCt/view?usp=sharing [5] https://lore.kernel.org/linux-mm/20251116013223.1557158-3-jiaqiyan@google.com Jiaqi Yan (3): mm/memory-failure: set has_hwpoisoned flags on HugeTLB folio mm/page_alloc: only free healthy pages in high-order HWPoison folio mm/memory-failure: simplify __page_handle_poison include/linux/page-flags.h | 2 +- mm/memory-failure.c | 32 +++--------- mm/page_alloc.c | 101 +++++++++++++++++++++++++++++++++++++ 3 files changed, 108 insertions(+), 27 deletions(-) -- 2.52.0.322.g1dd061c0dc-goog