From: Matthew Wilcox <willy@infradead.org>
To: jane.chu@oracle.com
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
David Hildenbrand <david@kernel.org>,
Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org,
Christian Brauner <christian@brauner.io>,
Jiaqi Yan <jiaqiyan@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v7 01/13] memory-failure: Fix hardware poison check in unpoison_memory() again
Date: Fri, 31 Jul 2026 14:39:01 +0100 [thread overview]
Message-ID: <amyldelTLZNeGaNQ@casper.infradead.org> (raw)
In-Reply-To: <c5b01c38-9c35-468b-9fce-ff7e1e11b03f@oracle.com>
On Thu, Jul 30, 2026 at 10:39:57PM -0700, jane.chu@oracle.com wrote:
> I think I spot another pre-existing issue in unpoison_memory():
> the XXX line doesn't work for non-hugetlb free large folio because it'll
> just try to clear PG_hwpoison in the folio->page, not the precise 'pfn'
> page. Something like below could do.
>
>
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 51508a55c405..14915718ace5 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -2730,8 +2730,10 @@ int unpoison_memory(unsigned long pfn)
> count = folio_free_raw_hwp(folio, false);
> if (count == 0)
> goto unlock_mutex;
> + else
> + ret = folio_test_clear_hwpoison(folio) ? 0 :
> -EBUSY;
> }
> - ret = folio_test_clear_hwpoison(folio) ? 0 : -EBUSY; <---
> XXX
> + ret = TestClearPageHWPoison(p) ? 0 : -EBUSY;
> } else if (ghp < 0) {
> if (ghp == -EHWPOISON) {
> ret = put_page_back_buddy(p) ? 0 : -EBUSY;
I think you're right, but this isn't a bug. That is, we're calling the
wrong function, but in this particular branch, we're guaranteed that
'folio' and 'p' have the same value so the same bit is cleared.
This is the case where !ghp is true. Here's the code we're looking at:
ghp = get_hwpoison_page(p, MF_UNPOISON);
if (!ghp) {
if (folio_test_hugetlb(folio)) {
huge = true;
count = folio_free_raw_hwp(folio, false);
if (count == 0)
goto unlock_mutex;
}
ret = folio_test_clear_hwpoison(folio) ? 0 : -EBUSY;
It is my understanding that we take this path for hugetlb memory and
pages which are in the buddy allocator. Buddy pages aren't compound
pages, so calling page_folio() on them returns the same pointer, just
cast to a folio.
Now, I do fix this in "hugetlb: Use the has_hwpoisoned flag" (because
nobody gets to use folio_test_clear_hwpoison() any more):
@@ -2733,8 +2756,10 @@ int unpoison_memory(unsigned long pfn)
hugetlb_unlock_irq();
goto unlock_mutex;
}
+ ret = hugetlb_clear_poison(folio);
+ } else {
+ ret = TestClearPageHWPoison(p) ? 0 : -EBUSY;
}
- ret = folio_test_clear_hwpoison(folio) ? 0 : -EBUSY;
hugetlb_unlock_irq();
} else if (ghp < 0) {
if (ghp == -EHWPOISON) {
so I agree with you this should be fixed. But I don't think it fixes
an actual bug. If it did, then we should do that first for easier
backporting. So if I've got anything wrong here, it's worth saying.
next prev parent reply other threads:[~2026-07-31 13:39 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 20:43 [PATCH v7 00/13] Use generic_file_read_iter() in hugetlbfs Matthew Wilcox (Oracle)
2026-07-28 20:43 ` [PATCH v7 01/13] memory-failure: Fix hardware poison check in unpoison_memory() again Matthew Wilcox (Oracle)
2026-07-29 0:39 ` Gregory Price
2026-07-29 1:43 ` Matthew Wilcox
2026-07-30 8:45 ` Miaohe Lin
2026-07-31 5:39 ` jane.chu
2026-07-31 13:39 ` Matthew Wilcox [this message]
2026-07-28 20:43 ` [PATCH v7 02/13] mm: Rename folio_contain_hwpoison_page() to folio_has_hwpoison_page() Matthew Wilcox (Oracle)
2026-07-30 8:53 ` Miaohe Lin
2026-07-31 6:07 ` jane.chu
2026-07-28 20:43 ` [PATCH v7 03/13] hugetlb: Mark some function arguments as const Matthew Wilcox (Oracle)
2026-07-30 8:57 ` Miaohe Lin
2026-07-28 20:43 ` [PATCH v7 04/13] guest_memfd: Use folio_has_hwpoisoned_page() Matthew Wilcox (Oracle)
2026-07-28 20:43 ` [PATCH v7 05/13] hugetlb: Move poison to pages before clearing hugetlb page type Matthew Wilcox (Oracle)
2026-07-29 0:41 ` Gregory Price
2026-07-30 11:40 ` Miaohe Lin
2026-07-28 20:43 ` [PATCH v7 06/13] hugetlb: Use the has_hwpoisoned flag Matthew Wilcox (Oracle)
2026-07-29 1:36 ` Gregory Price
2026-07-29 2:55 ` Matthew Wilcox
2026-07-29 15:05 ` Matthew Wilcox
2026-07-29 16:45 ` Gregory Price
2026-07-28 20:43 ` [PATCH v7 07/13] mm: Remove locking mf_mutex in is_raw_hwpoison_page_in_hugepage() Matthew Wilcox (Oracle)
2026-07-28 20:44 ` [PATCH v7 08/13] mm: Check individual hugetlb pages for poison Matthew Wilcox (Oracle)
2026-07-28 20:44 ` [PATCH v7 09/13] filemap: Add hwpoison handling to filemap_read() Matthew Wilcox (Oracle)
2026-07-28 20:44 ` [PATCH v7 10/13] filemap: Remove checks in mapping_set_folio_order_range() Matthew Wilcox (Oracle)
2026-07-28 20:44 ` [PATCH v7 11/13] hugetlb: Set mapping folio order Matthew Wilcox (Oracle)
2026-07-28 20:44 ` [PATCH v7 12/13] filemap: Add support for authoritative mappings Matthew Wilcox (Oracle)
2026-07-28 20:44 ` [PATCH v7 13/13] hugetlb: replace hugetlbfs_read_iter() with generic_file_read_iter() Matthew Wilcox (Oracle)
2026-07-29 15:17 ` [PATCH v7 00/13] Use generic_file_read_iter() in hugetlbfs Matthew Wilcox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=amyldelTLZNeGaNQ@casper.infradead.org \
--to=willy@infradead.org \
--cc=akpm@linux-foundation.org \
--cc=christian@brauner.io \
--cc=david@kernel.org \
--cc=jack@suse.cz \
--cc=jane.chu@oracle.com \
--cc=jiaqiyan@google.com \
--cc=linmiaohe@huawei.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox