From: Lyude Paul <lyude@redhat.com>
To: Alistair Popple <apopple@nvidia.com>,
Ben Skeggs <bskeggs@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, nouveau@lists.freedesktop.org,
John Hubbard <jhubbard@nvidia.com>,
Ralph Campbell <rcampbell@nvidia.com>
Subject: Re: [PATCH] nouveau: Fix migrate_to_ram() for faulting page
Date: Fri, 21 Oct 2022 15:53:19 -0400 [thread overview]
Message-ID: <bdaca873243ca55de9b286d732c46729f2d96415.camel@redhat.com> (raw)
In-Reply-To: <20221019122934.866205-1-apopple@nvidia.com>
On Wed, 2022-10-19 at 23:29 +1100, Alistair Popple wrote:
> Commit 16ce101db85d ("mm/memory.c: fix race when faulting a device private
> page") changed the migrate_to_ram() callback to take a reference on the
> device page to ensure it can't be freed while handling the fault.
> Unfortunately the corresponding update to Nouveau to accommodate this
> change was inadvertently dropped from that patch causing GPU to CPU
> migration to fail so add it here.
>
> Signed-off-by: Alistair Popple <apopple@nvidia.com>
> Fixes: 16ce101db85d ("mm/memory.c: fix race when faulting a device private page")
> Cc: John Hubbard <jhubbard@nvidia.com>
> Cc: Ralph Campbell <rcampbell@nvidia.com>
> Cc: Lyude Paul <lyude@redhat.com>
> Cc: Ben Skeggs <bskeggs@redhat.com>
>
> ---
>
> Hi Andrew/Ben, apologies I must have accidentally dropped this small hunk
> when rebasing prior to sending v2 of the original series. Without this
> migration from GPU to CPU won't work in Nouveau so hopefully one of you can
> take this for v6.1-rcX. Thanks.
Hi!
Reviewed-by: Lyude Paul <lyude@redhat.com>
I will push this to drm-misc-next in just a moment, thanks for the patch!
> ---
> drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_dmem.c b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> index 5fe209107246..20fe53815b20 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_dmem.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_dmem.c
> @@ -176,6 +176,7 @@ static vm_fault_t nouveau_dmem_migrate_to_ram(struct vm_fault *vmf)
> .src = &src,
> .dst = &dst,
> .pgmap_owner = drm->dev,
> + .fault_page = vmf->page,
> .flags = MIGRATE_VMA_SELECT_DEVICE_PRIVATE,
> };
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
next prev parent reply other threads:[~2022-10-21 19:53 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 12:29 Alistair Popple
2022-10-21 19:53 ` Lyude Paul [this message]
2022-10-21 20:49 ` Andrew Morton
2022-10-21 21:10 ` Lyude Paul
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=bdaca873243ca55de9b286d732c46729f2d96415.camel@redhat.com \
--to=lyude@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bskeggs@redhat.com \
--cc=jhubbard@nvidia.com \
--cc=linux-mm@kvack.org \
--cc=nouveau@lists.freedesktop.org \
--cc=rcampbell@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox