| 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: <225f0193-e27d-bad7-56ec-09cdaed64f71@huawei.com>
Date: Thu, 5 Feb 2026 15:18:44 +0800
From: Miaohe Lin <linmiaohe@...wei.com>
To: Zi Yan <ziy@...dia.com>, <jane.chu@...cle.com>
CC: "David Hildenbrand (arm)" <david@...nel.org>, 是参差
<shicenci@...il.com>, <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 11:53, Zi Yan wrote:
> On 4 Feb 2026, at 22:21, Miaohe Lin wrote:
>
>> 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?
>
> No. All folios (including pre-mapped/mTHP ones) are large_rmappable.
>
>>
>> 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.
>> .
>
> This makes sense to me. And it gets rid of the warning as well.
>
> Can you send a proper patch of this?
>
> Feel free to add
>
> Reviewed-by: Zi Yan <ziy@...dia.com>
> Tested-by: Zi Yan <ziy@...dia.com>
Sure. Thanks for all of your work. :)
Powered by blists - more mailing lists