linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Jinjiang Tu <tujinjiang@huawei.com>,
	akpm@linux-foundation.org, linmiaohe@huawei.com
Cc: linux-mm@kvack.org, wangkefeng.wang@huawei.com
Subject: Re: [PATCH] mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list
Date: Wed, 11 Jun 2025 10:35:58 +0200	[thread overview]
Message-ID: <1f0c7d73-b7e2-4ee9-8050-f23c05e75e8b@redhat.com> (raw)
In-Reply-To: <de717d45-506d-17ad-d442-1e2766c61801@huawei.com>

On 11.06.25 10:29, Jinjiang Tu wrote:
> 
> 在 2025/6/11 15:59, David Hildenbrand 写道:
>> On 11.06.25 09:46, Jinjiang Tu wrote:
>>> In shrink_folio_list(), the hwpoisoned folio may be large folio, which
>>> can't be handled by unmap_poisoned_folio().
>>>
>>> Since UCE is rare in real world, and race with reclaimation is more
>>> rare,
>>> just skipping the hwpoisoned large folio is enough. memory_failure()
>>> will
>>> handle it if the UCE is triggered again.
>>>
>>> Fixes: 1b0449544c64 ("mm/vmscan: don't try to reclaim hwpoison folio")
>>
>> Please also add
>>
>> Closes:
>>
>> with a link to the report
> Thanks, I will add it.
>>
>>> Reported-by: syzbot+3b220254df55d8ca8a61@syzkaller.appspotmail.com
>>> Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
>>> ---
>>>    mm/vmscan.c | 8 ++++++++
>>>    1 file changed, 8 insertions(+)
>>> /home/tujinjiang/hulk-repo/hulk/mm/mempolicy.c
>>> diff --git a/mm/vmscan.c b/mm/vmscan.c
>>> index b6f4db6c240f..3a4e8d7419ae 100644
>>> --- a/mm/vmscan.c
>>> +++ b/mm/vmscan.c
>>> @@ -1131,6 +1131,14 @@ static unsigned int shrink_folio_list(struct
>>> list_head *folio_list,
>>>                goto keep;
>>>              if (folio_contain_hwpoisoned_page(folio)) {
>>> +            /*
>>> +             * unmap_poisoned_folio() can't handle large
>>> +             * folio, just skip it. memory_failure() will
>>> +             * handle it if the UCE is triggered again.
>>> +             */
>>> +            if (folio_test_large(folio))
>>> +                goto keep_locked;
>>> +
>>>                unmap_poisoned_folio(folio, folio_pfn(folio), false);
>>>                folio_unlock(folio);
>>>                folio_put(folio);
>>
>> Why not handle that in unmap_poisoned_folio() to make that limitation
>> clear and avoid?
> I tried to put the check in unmap_poisoned_folio(), but it still exists
> other issues.



> The calltrace in v6.6 kernel:
> 
> Unable to handle kernel paging request at virtual address fbd5200000000024
> KASAN: maybe wild-memory-access in range
> [0xdead000000000120-0xdead000000000127]
> pc : __list_add_valid_or_report+0x50/0x158 lib/list_debug.c:32
> lr : __list_add_valid include/linux/list.h:88 [inline]
> lr : __list_add include/linux/list.h:150 [inline]
> lr : list_add_tail include/linux/list.h:183 [inline]
> lr : lru_add_page_tail.constprop.0+0x4ac/0x640 mm/huge_memory.c:3187
> Call trace:
>    __list_add_valid_or_report+0x50/0x158 lib/list_debug.c:32
>    __list_add_valid include/linux/list.h:88 [inline]
>    __list_add include/linux/list.h:150 [inline]
>    list_add_tail include/linux/list.h:183 [inline]
>    lru_add_page_tail.constprop.0+0x4ac/0x640 mm/huge_memory.c:3187
>    __split_huge_page_tail.isra.0+0x344/0x508 mm/huge_memory.c:3286
>    __split_huge_page+0x244/0x1270 mm/huge_memory.c:3317
>    split_huge_page_to_list_to_order+0x1038/0x1620 mm/huge_memory.c:3625
>    split_folio_to_list_to_order include/linux/huge_mm.h:638 [inline]
>    split_folio_to_order include/linux/huge_mm.h:643 [inline]
>    deferred_split_scan+0x5f8/0xb70 mm/huge_memory.c:3778
>    do_shrink_slab+0x2a0/0x828 mm/vmscan.c:927
>    shrink_slab_memcg+0x2c0/0x558 mm/vmscan.c:996
>    shrink_slab+0x228/0x250 mm/vmscan.c:1075
>    shrink_node_memcgs+0x34c/0x6a0 mm/vmscan.c:6630
>    shrink_node+0x21c/0x1378 mm/vmscan.c:6664
>    shrink_zones.constprop.0+0x24c/0xab0 mm/vmscan.c:6906
>    do_try_to_free_pages+0x150/0x880 mm/vmscan.c:6968
> 
> 
> The folio is deleted from lru and the folio->lru can't be accessed. If
> the folio is splitted later,
> lru_add_split_folio() assumes the folio is on lru.

Not sure if something like the following would be appropriate:

diff --git a/mm/memory-failure.c b/mm/memory-failure.c
index b91a33fb6c694..fdd58c8ba5254 100644
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -1566,6 +1566,9 @@ int unmap_poisoned_folio(struct folio *folio, unsigned long pfn, bool must_kill)
         enum ttu_flags ttu = TTU_IGNORE_MLOCK | TTU_SYNC | TTU_HWPOISON;
         struct address_space *mapping;
  
+       if (folio_test_large && !folio_test_hugetlb(folio))
+               return -EBUSY;
+
         if (folio_test_swapcache(folio)) {
                 pr_err("%#lx: keeping poisoned page in swap cache\n", pfn);
                 ttu &= ~TTU_HWPOISON;
diff --git a/mm/vmscan.c b/mm/vmscan.c
index f8dfd2864bbf4..6a3426bc9e9d7 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1138,7 +1138,8 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
                         goto keep;
  
                 if (folio_contain_hwpoisoned_page(folio)) {
-                       unmap_poisoned_folio(folio, folio_pfn(folio), false);
+                       if (unmap_poisoned_folio(folio, folio_pfn(folio), false)){
+                               list_add(&folio->lru, &ret_folios);
                         folio_unlock(folio);
                         folio_put(folio);
                         continue;

-- 
Cheers,

David / dhildenb



  reply	other threads:[~2025-06-11  8:36 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-06-11  7:46 [PATCH] mm/vmscan: fix hwpoisoned large folio handling in shrink_folio_list Jinjiang Tu
2025-06-11  7:59 ` David Hildenbrand
2025-06-11  8:29   ` Jinjiang Tu
2025-06-11  8:35     ` David Hildenbrand [this message]
2025-06-11  9:00       ` Jinjiang Tu
2025-06-11  9:20         ` David Hildenbrand
2025-06-11  9:24           ` David Hildenbrand
2025-06-11 14:30             ` Zi Yan
2025-06-11 17:34               ` David Hildenbrand
2025-06-11 17:52                 ` Zi Yan
2025-06-12  7:53                   ` David Hildenbrand
2025-06-12 15:35                     ` Zi Yan
2025-06-12 15:50                       ` David Hildenbrand
2025-06-12 16:48                         ` Zi Yan
2025-06-16 11:34                           ` Jinjiang Tu
2025-06-16 11:33                         ` Jinjiang Tu
2025-06-16 19:27                           ` David Hildenbrand
2025-06-17  6:43                             ` Jinjiang Tu

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=1f0c7d73-b7e2-4ee9-8050-f23c05e75e8b@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=tujinjiang@huawei.com \
    --cc=wangkefeng.wang@huawei.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;
as well as URLs for NNTP newsgroup(s).