From: Jason Gunthorpe <jgg@nvidia.com>
To: Felix Kuehling <felix.kuehling@amd.com>
Cc: Alistair Popple <apopple@nvidia.com>, Philip Yang <yangp@amd.com>,
Philip Yang <Philip.Yang@amd.com>,
amd-gfx@lists.freedesktop.org, Linux MM <linux-mm@kvack.org>,
Leon Romanovsky <leonro@nvidia.com>
Subject: Re: [PATCH] drm/amdkfd: Fix svm_bo and vram page refcount
Date: Mon, 6 Oct 2025 15:35:02 -0300 [thread overview]
Message-ID: <20251006183502.GV3360665@nvidia.com> (raw)
In-Reply-To: <b81d7333-192d-4b67-b270-ab9736a48589@amd.com>
On Mon, Oct 06, 2025 at 01:51:37PM -0400, Felix Kuehling wrote:
> OK. We made an incorrect assumption that we can reuse a page if the
> driver isn't tracking it as allocated to any of our SVM ranges (i.e.,
> after dev_pagemap_ops.migrate_to_ram() migrated all data out of the
> page). However, we neglected that other parts of the kernel can still
> hold references to a page even after that.
Yes, that sounds completely incorrect.
> As I understand it, it's a race condition. The driver is done with the
> page and its migrate_to_ram() call has completed. But do_swap_page
> hasn't called put_page yet. At the same time, another thread is trying
> to reuse the page, migrating data back to VRAM.
Which means the driver is not properly tracking freed pages.
I don't think the code you showed makes alot of sense, if someone else
has a reference on the page it could be for many reasons. If you take
a non-free page and treat it as free and safe to use you probably are
adding a security bug.
Jason
prev parent reply other threads:[~2025-10-07 7:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 21:03 [PATCH] drm/amdkfd: Fix svm_bo and vram page refcount Philip Yang
2025-09-26 21:38 ` Kasiviswanathan, Harish
2025-09-30 14:38 ` James Zhu
2025-09-30 15:48 ` Mario Limonciello
2025-10-03 21:05 ` Felix Kuehling
2025-10-03 21:18 ` Philip Yang
2025-10-03 21:46 ` Felix Kuehling
2025-10-03 22:02 ` Philip Yang
2025-10-03 22:16 ` Felix Kuehling
2025-10-06 12:55 ` Philip Yang
2025-10-06 13:21 ` Jason Gunthorpe
2025-10-06 17:51 ` Felix Kuehling
2025-10-06 18:35 ` Jason Gunthorpe [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=20251006183502.GV3360665@nvidia.com \
--to=jgg@nvidia.com \
--cc=Philip.Yang@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=apopple@nvidia.com \
--cc=felix.kuehling@amd.com \
--cc=leonro@nvidia.com \
--cc=linux-mm@kvack.org \
--cc=yangp@amd.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.