All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alistair Popple <apopple@nvidia.com>
To: liuqiangneo@163.com
Cc: jgg@ziepe.ca, leon@kernel.org, akpm@linux-foundation.org,
	 linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Qiang Liu <liuqiang@kylinos.cn>
Subject: Re: [PATCH] lib/test_hmm: Check alloc_page_vma() return value
Date: Fri, 15 May 2026 15:50:26 +1000	[thread overview]
Message-ID: <agayR-p7WbncrRCf@nvdebian.thelocal> (raw)
In-Reply-To: <20260514032345.32256-1-liuqiangneo@163.com>

On 2026-05-14 at 13:23 +1000, liuqiangneo@163.com wrote...
> From: Qiang Liu <liuqiang@kylinos.cn>
> 
> Return VM_FAULT_OOM if page allocation fails, which
> avoids a NULL pointer dereference when calling lock_page().

Thanks, I agree the NULL dereference is a bug and this avoids it but what
happens to the pages that may have already been allocated and locked in previous
iterations of the loop? I think the subsequent migrate_vma_pages()/finalize()
calls will do the correct thing, but that would lead to a partial migration.

Given that's not what we're explicitly testing here I think it would be better
to just unlock and free the previously allocated pages before returning.

 - Alistair
 
> Signed-off-by: Qiang Liu <liuqiang@kylinos.cn>
> ---
>  lib/test_hmm.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/lib/test_hmm.c b/lib/test_hmm.c
> index 213504915737..f8b43d6eb261 100644
> --- a/lib/test_hmm.c
> +++ b/lib/test_hmm.c
> @@ -1063,6 +1063,8 @@ static vm_fault_t dmirror_devmem_fault_alloc_and_copy(struct migrate_vma *args,
>  			/* Try with smaller pages if large allocation fails */
>  			if (!dpage && order) {
>  				dpage = alloc_page_vma(GFP_HIGHUSER_MOVABLE, args->vma, addr);
> +				if (!dpage)
> +					return VM_FAULT_OOM;
>  				lock_page(dpage);
>  				dst[i] = migrate_pfn(page_to_pfn(dpage));
>  				dst_page = pfn_to_page(page_to_pfn(dpage));
> -- 
> 2.43.0
> 
> 


      reply	other threads:[~2026-05-15  5:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-14  3:23 [PATCH] lib/test_hmm: Check alloc_page_vma() return value liuqiangneo
2026-05-15  5:50 ` Alistair Popple [this message]

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=agayR-p7WbncrRCf@nvdebian.thelocal \
    --to=apopple@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuqiang@kylinos.cn \
    --cc=liuqiangneo@163.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.