Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Ye Liu <ye.liu@linux.dev>
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 05:36:59 +0200	[thread overview]
Message-ID: <agPx2woN458Co5Us@localhost.localdomain> (raw)
In-Reply-To: <20260513024853.65566-1-ye.liu@linux.dev>

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)) {


-- 
Oscar Salvador
SUSE Labs


  reply	other threads:[~2026-05-13  3:37 UTC|newest]

Thread overview: 4+ 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 [this message]
2026-05-13  6:50   ` Ye Liu
2026-05-13  8:38     ` Oscar Salvador

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=agPx2woN458Co5Us@localhost.localdomain \
    --to=osalvador@suse.de \
    --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=ye.liu@linux.dev \
    /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