From: Miaohe Lin <linmiaohe@huawei.com>
To: jane.chu@oracle.com, "Zi Yan" <ziy@nvidia.com>,
"David Hildenbrand (arm)" <david@kernel.org>,
是参差 <shicenci@gmail.com>
Cc: <linux-mm@kvack.org>, <akpm@linux-foundation.org>,
<linux-kernel@vger.kernel.org>,
Matthew Wilcox <willy@infradead.org>
Subject: Re: WARNING in memory_failure() at include/linux/huge_mm.h:635 triggered
Date: Thu, 5 Feb 2026 11:21:09 +0800 [thread overview]
Message-ID: <c5206f67-1e9e-d487-3514-8867f00cc626@huawei.com> (raw)
In-Reply-To: <7d5754dd-8cf5-41f3-a767-271b28b1f63c@oracle.com>
On 2026/2/5 10:00, jane.chu@oracle.com wrote:
>
>
> On 2/4/2026 1:41 PM, Zi Yan wrote:
>> On 4 Feb 2026, at 16:37, David Hildenbrand (arm) wrote:
>>
>>> On 2/4/26 22:08, Zi Yan wrote:
>>>> On 4 Feb 2026, at 14:18, David Hildenbrand (arm) wrote:
>>>>
>>>>> On 2/4/26 18:41, Zi Yan wrote:
>>>>>>
>>>>>>
>>>>>> More details:
>>>>>> later at sg_vma_fault(), the driver just handles a page fault by supplying
>>>>>> a subpage from a pre-allocated compound page[3]. We then get a large folio
>>>>>> without !CONFIG_TRANSPARENT_HUGEPAGE.
>>>>>
>>>>> We can identify such non-folio (but compound) things by looking at PG_large_rmappable IIRC.
>>>>
>>>> OK, back to the issue. The patch below should fix the issue?
>>>>
>>>> Hi 是参差,
>>>>
>>>> Can you test it?
>>>>
>>
>> <snip>
>>> I think you have to test for folio_test_large() before testing folio_test_large_rmappable().
>>
>> Oh, forgot that. Thanks.
>>
>>
>> From 8dda4bba9964890462eca3ef3cce57bb4fab8313 Mon Sep 17 00:00:00 2001
>> From: Zi Yan <ziy@nvidia.com>
>> Date: Wed, 4 Feb 2026 16:04:19 -0500
>> Subject: [PATCH] mm/memory_failure: reject unsupported non-folio compound page
>>
>> Signed-off-by: Zi Yan <ziy@nvidia.com>
>> ---
>> mm/memory-failure.c | 8 ++++++--
>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index 825c706ac576..137c67fda57e 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -2440,9 +2440,13 @@ int memory_failure(unsigned long pfn, int flags)
>>
>> folio = page_folio(p);
>>
>> - /* filter pages that are protected from hwpoison test by users */
>> + /*
>> + * filter pages that are protected from hwpoison test by users
>> + * or unsupported non folio compound pages
>> + */
>> folio_lock(folio);
>> - if (hwpoison_filter(p)) {
>> + if (hwpoison_filter(p) ||
>> + (folio_test_large(folio) && !folio_test_large_rmappable(folio))) {
>
> Just curious, would this filter out pte-mapped THP/mTHP folios?
Thanks all.
memory_failure() can meet various types of folios. So in get_hwpoison_page(),
HWPoisonHandlable() and PageHuge() are used to check whether the folio can
be handled. But in madvise(MADV_HWPOISON) scene, MF_COUNT_INCREASED is set in
flag, so this check is skipped and warning triggered. Might HWPoisonHandlable()
check be always used to make sure the folio is in sane types? Something like
below (i.e. remove the MF_COUNT_INCREASED check before calling get_hwpoison_page):
diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index 825c706ac576..ba4231858a36 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -2411,31 +2411,29 @@ int memory_failure(unsigned long pfn, int flags)
* In fact it's dangerous to directly bump up page count from 0,
* that may make page_ref_freeze()/page_ref_unfreeze() mismatch.
*/
- if (!(flags & MF_COUNT_INCREASED)) {
- res = get_hwpoison_page(p, flags);
- if (!res) {
- if (is_free_buddy_page(p)) {
- if (take_page_off_buddy(p)) {
- page_ref_inc(p);
- res = MF_RECOVERED;
- } else {
- /* We lost the race, try again */
- if (retry) {
- ClearPageHWPoison(p);
- retry = false;
- goto try_again;
- }
- res = MF_FAILED;
- }
- res = action_result(pfn, MF_MSG_BUDDY, res);
+ res = get_hwpoison_page(p, flags);
+ if (!res) {
+ if (is_free_buddy_page(p)) {
+ if (take_page_off_buddy(p)) {
+ page_ref_inc(p);
+ res = MF_RECOVERED;
} else {
- res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED);
+ /* We lost the race, try again */
+ if (retry) {
+ ClearPageHWPoison(p);
+ retry = false;
+ goto try_again;
+ }
+ res = MF_FAILED;
}
- goto unlock_mutex;
- } else if (res < 0) {
- res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED);
- goto unlock_mutex;
+ res = action_result(pfn, MF_MSG_BUDDY, res);
+ } else {
+ res = action_result(pfn, MF_MSG_KERNEL_HIGH_ORDER, MF_IGNORED);
}
+ goto unlock_mutex;
+ } else if (res < 0) {
+ res = action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED);
+ goto unlock_mutex;
}
folio = page_folio(p);
Thanks.
.
next prev parent reply other threads:[~2026-02-05 3:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-04 12:49 是参差
2026-02-04 17:12 ` David Hildenbrand (arm)
2026-02-04 17:15 ` David Hildenbrand (arm)
2026-02-04 17:23 ` Zi Yan
2026-02-04 17:34 ` Zi Yan
2026-02-04 17:41 ` Zi Yan
2026-02-04 19:18 ` David Hildenbrand (arm)
2026-02-04 19:48 ` Zi Yan
2026-02-04 19:55 ` David Hildenbrand (arm)
2026-02-04 20:13 ` Zi Yan
2026-02-04 20:31 ` David Hildenbrand (arm)
2026-02-04 20:45 ` Zi Yan
2026-02-04 21:14 ` David Hildenbrand (arm)
2026-02-04 21:08 ` Zi Yan
2026-02-04 21:37 ` David Hildenbrand (arm)
2026-02-04 21:41 ` Zi Yan
2026-02-05 2:00 ` jane.chu
2026-02-05 3:21 ` Miaohe Lin [this message]
2026-02-05 3:53 ` Zi Yan
2026-02-05 7:18 ` Miaohe Lin
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=c5206f67-1e9e-d487-3514-8867f00cc626@huawei.com \
--to=linmiaohe@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jane.chu@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=shicenci@gmail.com \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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