| 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: <85CB7DEA-79EE-43EE-BA9B-C2AC81F6FA02@nvidia.com>
Date: Wed, 04 Feb 2026 22:53:48 -0500
From: Zi Yan <ziy@...dia.com>
To: Miaohe Lin <linmiaohe@...wei.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 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>
to it. Thanks.
--
Best Regards,
Yan, Zi
Powered by blists - more mailing lists