| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <c5206f67-1e9e-d487-3514-8867f00cc626@huawei.com>
Date: Thu, 5 Feb 2026 11:21:09 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: <jane.chu@...cle.com>, Zi Yan <ziy@...dia.com>, "David Hildenbrand (arm)"
<david@...nel.org>, 是参差 <shicenci@...il.com>
CC: <linux-mm@...ck.org>, <akpm@...ux-foundation.org>,
<linux-kernel@...r.kernel.org>, Matthew Wilcox <willy@...radead.org>
Subject: Re: WARNING in memory_failure() at include/linux/huge_mm.h:635
triggered
On 2026/2/5 10:00, jane.chu@...cle.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@...dia.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@...dia.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.
.
Powered by blists - more mailing lists