All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ye Liu <ye.liu@linux.dev>
To: Oscar Salvador <osalvador@suse.de>
Cc: Miaohe Lin <linmiaohe@huawei.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ye Liu <liuye@kylinos.cn>,
	Naoya Horiguchi <nao.horiguchi@gmail.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RESEND PATCH] mm/memory_failure: use bool for hugetlb indicator in try_memory_failure_hugetlb
Date: Wed, 13 May 2026 14:50:56 +0800	[thread overview]
Message-ID: <fe1f36ac-84f1-4557-9411-41497737224d@linux.dev> (raw)
In-Reply-To: <agPx2woN458Co5Us@localhost.localdomain>



在 2026/5/13 11:36, Oscar Salvador 写道:
> On Wed, May 13, 2026 at 10:48:52AM +0800, Ye Liu wrote:
>> From: Ye Liu <liuye@kylinos.cn>
>>
>> The hugetlb indicator in try_memory_failure_hugetlb is a Boolean
>> flag, but was declared and assigned as int/0/1. Convert to `bool`
>> and `true`/`false` for clarity and type safety.
>>
>> - try_memory_failure_hugetlb(unsigned long pfn, int flags, bool *hugetlb)
>> - testcase path in memory_failure(): bool hugetlb = false
>> - clear semantic conversion in MF_HUGETLB_NON_HUGEPAGE
>> - preserve behavior (no functional change)
>>
>> Signed-off-by: Ye Liu <liuye@kylinos.cn>
>> Acked-by: Miaohe Lin <linmiaohe@huawei.com>
>> ---
>>  mm/memory-failure.c | 10 +++++-----
>>  1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>> index 866c4428ac7e..f164fc5959f0 100644
>> --- a/mm/memory-failure.c
>> +++ b/mm/memory-failure.c
>> @@ -2032,7 +2032,7 @@ int __get_huge_page_for_hwpoison(unsigned long pfn, int flags,
>>   *	-EHWPOISON	- folio or exact page already poisoned
>>   *	-EFAULT		- kill_accessing_process finds current->mm null
>>   */
>> -static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb)
>> +static int try_memory_failure_hugetlb(unsigned long pfn, int flags, bool *hugetlb)
>>  {
>>  	int res, rv;
>>  	struct page *p = pfn_to_page(pfn);
>> @@ -2040,12 +2040,12 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb
>>  	unsigned long page_flags;
>>  	bool migratable_cleared = false;
>>  
>> -	*hugetlb = 1;
>> +	*hugetlb = true;
>>  retry:
>>  	res = get_huge_page_for_hwpoison(pfn, flags, &migratable_cleared);
>>  	switch (res) {
>>  	case MF_HUGETLB_NON_HUGEPAGE:	/* fallback to normal page handling */
>> -		*hugetlb = 0;
>> +		*hugetlb = false;
> 
> Do we really need this boolean though?
> Why do not simply return ENOENT when we find a non-hugetlb page, and then the caller
> knows that if we get ENOENT, it can proceed with normal page handling?
> 
> I might be missing something, but is not the following more cleaer?
> 
>  diff --git a/mm/memory-failure.c b/mm/memory-failure.c
>  index ee42d4361309..44f388df5731 100644
>  --- a/mm/memory-failure.c
>  +++ b/mm/memory-failure.c
>  @@ -2026,13 +2026,14 @@ int __get_huge_page_for_hwpoison(unsigned long pfn, int flags,
>    * So some of prechecks for hwpoison (pinning, and testing/setting
>    * PageHWPoison) should be done in single hugetlb_lock range.
>    * Returns:
>  - *     0               - not hugetlb, or recovered
>  + *     0               - recovered
>  + *     -ENOENT         - no hugetlb page
>    *     -EBUSY          - not recovered
>    *     -EOPNOTSUPP     - hwpoison_filter'ed
>    *     -EHWPOISON      - folio or exact page already poisoned
>    *     -EFAULT         - kill_accessing_process finds current->mm null
>    */
>  -static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb)
>  +static int try_memory_failure_hugetlb(unsigned long pfn, int flags)
>   {
>          int res, rv;
>          struct page *p = pfn_to_page(pfn);
>  @@ -2040,13 +2041,11 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb
>          unsigned long page_flags;
>          bool migratable_cleared = false;
>  
>  -       *hugetlb = 1;
>   retry:
>          res = get_huge_page_for_hwpoison(pfn, flags, &migratable_cleared);
>          switch (res) {
>          case MF_HUGETLB_NON_HUGEPAGE:   /* fallback to normal page handling */
>  -               *hugetlb = 0;
>  -               return 0;
>  +               return -ENOENT;
>          case MF_HUGETLB_RETRY:
>                  if (!(flags & MF_NO_RETRY)) {
>                          flags |= MF_NO_RETRY;
>  @@ -2107,7 +2106,7 @@ static int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb
>   }
>  
>   #else
>  -static inline int try_memory_failure_hugetlb(unsigned long pfn, int flags, int *hugetlb)
>  +static inline int try_memory_failure_hugetlb(unsigned long pfn, int flags)
>   {
>          return 0;
>   }
>  @@ -2386,8 +2385,11 @@ int memory_failure(unsigned long pfn, int flags)
>          }
>  
>   try_again:
>  -       res = try_memory_failure_hugetlb(pfn, flags, &hugetlb);
>  -       if (hugetlb)
>  +       res = try_memory_failure_hugetlb(pfn, flags);
>  +       /*
>  +        * -ENOENT means the page we found is not hugetlb, so proceed with normal page handling
>  +        */
>  +       if (res != -ENOENT)
>                  goto unlock_mutex;
>  
>          if (TestSetPageHWPoison(p)) {
> 
> 


Hi Oscar,

Good point.  Using -ENOENT to distinguish "not a hugetlb page" from
"hugetlb handled" is indeed cleaner than carrying an extra output
parameter.

One thing to note: the #else stub when CONFIG_HUGETLB_PAGE is not set
currently does:

    return 0;

which with your change would mean "hugetlb handled, skip normal path"
instead of the intended "not hugetlb, proceed with normal handling".
It should be changed to:

    return -ENOENT;

Otherwise the non-hugetlb config would silently skip all normal page
failure processing.

-- 
Thanks,
Ye Liu



  reply	other threads:[~2026-05-13  6:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13  2:48 [RESEND PATCH] mm/memory_failure: use bool for hugetlb indicator in try_memory_failure_hugetlb Ye Liu
2026-05-13  3:36 ` Oscar Salvador
2026-05-13  6:50   ` Ye Liu [this message]
2026-05-13  8:38     ` Oscar Salvador
2026-05-14  2:34       ` Miaohe Lin

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=fe1f36ac-84f1-4557-9411-41497737224d@linux.dev \
    --to=ye.liu@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=linmiaohe@huawei.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuye@kylinos.cn \
    --cc=nao.horiguchi@gmail.com \
    --cc=osalvador@suse.de \
    /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.