All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Miaohe Lin <linmiaohe@huawei.com>, Jinjiang Tu <tujinjiang@huawei.com>
Cc: wangkefeng.wang@huawei.com, nao.horiguchi@gmail.com,
	akpm@linux-foundation.org, xueshuai@linux.alibaba.com,
	ziy@nvidia.com, osalvador@suse.de, linux-mm@kvack.org
Subject: Re: [PATCH v2] mm/memory-failure: fix infinite UCE for VM_PFNMAP'ed page
Date: Thu, 14 Aug 2025 08:40:26 +0200	[thread overview]
Message-ID: <871ed36d-796c-46ae-a522-89ce9a0fb5b1@redhat.com> (raw)
In-Reply-To: <c39474a9-31b2-7df8-8ce8-229f706b05de@huawei.com>

On 12.08.25 04:01, Miaohe Lin wrote:
> On 2025/8/11 12:33, Jinjiang Tu wrote:
>> When memory_failure() is called for a already hwpoisoned pfn backed with
>> struct page, kill_accessing_process() will conditionally send a SIGBUS to
>> the current (triggering) process if it maps the page.
>>
>> However, in case the page is not ordinarily mapped, but was mapped through
>> remap_pfn_range(), kill_accessing_process() wouldn't identify it as mapped
>> even though hwpoison_pte_range() would be prepared to handle it, because
>> walk_page_range() will skip VM_PFNMAP as default in walk_page_test(). As
>> a result, walk_page_range() will return 0, assuming "not mapped" and SIGBUS
>> will be skipped. The user task will trigger UCE infinitely because it will
>> not receive a SIGBUS on access and simply retry.
>>
>> Before commit aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes
>> with recovered clean pages"), kill_accessing_process() will return EFAULT.
>> For x86, the current task will be killed in kill_me_maybe().
>>
>> To fix it, add .test_walk callback for hwpoison_walk_ops to process
>> VM_PFNMAP VMAs too.
>>
>> Fixes: aaf99ac2ceb7 ("mm/hwpoison: do not send SIGBUS to processes with recovered clean pages")
>> Signed-off-by: Jinjiang Tu <tujinjiang@huawei.com>
>> ---
>> Changelog since v1:
>>   * update patch description, suggested by David Hildenbrand
>>
>>   mm/memory-failure.c | 7 +++++++
>>   1 file changed, 7 insertions(+)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index e2e685b971bb..fa6a8f2cdebc 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -853,9 +853,16 @@ static int hwpoison_hugetlb_range(pte_t *ptep, unsigned long hmask,
>>   #define hwpoison_hugetlb_range	NULL
>>   #endif
>>   
> 
> It might be better to add a comment on why below hwpoison_test_walk is needed.
> It looks somewhat weird as hwpoison_test_walk simply return 0.

Agreed.

/* We also want to consider pages mapped into VM_PFNMAP. */

Acked-by: David Hildenbrand <david@redhat.com>

-- 
Cheers

David / dhildenb



  reply	other threads:[~2025-08-14  6:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-11  4:33 [PATCH v2] mm/memory-failure: fix infinite UCE for VM_PFNMAP'ed page Jinjiang Tu
2025-08-11  7:54 ` David Hildenbrand
2025-08-12  2:01 ` Miaohe Lin
2025-08-14  6:40   ` David Hildenbrand [this message]
2025-08-15  1:16   ` Jinjiang Tu
2025-08-14  6:05 ` jane.chu
2025-08-15  1:16   ` 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=871ed36d-796c-46ae-a522-89ce9a0fb5b1@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-mm@kvack.org \
    --cc=nao.horiguchi@gmail.com \
    --cc=osalvador@suse.de \
    --cc=tujinjiang@huawei.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=xueshuai@linux.alibaba.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.