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
>
>
prev parent 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.