From: Jason Gunthorpe <jgg@nvidia.com>
To: David Hildenbrand <david@redhat.com>
Cc: Peter Xu <peterx@redhat.com>, Jinjiang Tu <tujinjiang@huawei.com>,
akpm@linux-foundation.org, lorenzo.stoakes@oracle.com,
Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, linux-mm@kvack.org,
wangkefeng.wang@huawei.com
Subject: Re: [PATCH] mm: fix COW mapping handing in generic_access_phys
Date: Wed, 28 May 2025 15:15:06 -0300 [thread overview]
Message-ID: <20250528181506.GA192531@nvidia.com> (raw)
In-Reply-To: <84a19161-765d-4aba-b42f-5fdd8c986bdf@redhat.com>
On Wed, May 28, 2025 at 08:00:34PM +0200, David Hildenbrand wrote:
> Having refcounted anon page in a VM_PFNMAP doesn't suddenly turn the whole
> thing into a MIXEDMAP where other things with a "struct page" are suddenly
> refcounted as well.
The special COW rules for PFNMAP require a single linear mapping so
that vma->vm_pgoff can encode the "special" range. So the only way to
get struct pages in a PFNMAP that also satisfy the COW rule is if you
have a single contiguous chunk of them.
Otherwise they turn into MIXEDMAP on non-special arches.
Which is a little detail I wonder how many DRM drivers trip up on :|
> ... and that should definitely be changed, such that MIXEDMAP is really only
> used when actually having non-refcounted things in there.
MIXEDMAP has to be used any time you can't meet the special rules that
remap_pfn_range() sets for PFNMAP.
Really I think we have three special cases, not just two:
VM_MIXEDMAP - The ptes can hold struct pages and if they do the refcount is
managed by the core code
VM_PFNMAP|VM_SHARED - The ptes can never be converted into struct pages, nothing
can ever refcount them and you can use fault/etc to store
things
VM_PFNMAP|!VM_SHARED - Must only be created by remap_pfn_range() and can store
exactly 1 contiguous range of address that cannot be converted to
struct pages and will never be refcounted. Probably can't
use fault
Most of my remarks are about the VM_PFNMAP|VM_SHARED case
For arches with the special bit VM_PFNMAP|!VM_SHARED == VM_MIXEDMAP
Jason
next prev parent reply other threads:[~2025-05-28 18:15 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-28 1:56 [PATCH] mm: fix COW mapping handing in generic_access_phys Jinjiang Tu
2025-05-28 8:59 ` David Hildenbrand
2025-05-28 9:59 ` David Hildenbrand
2025-05-28 12:14 ` Jinjiang Tu
2025-05-28 14:54 ` Peter Xu
2025-05-28 15:02 ` David Hildenbrand
2025-05-28 15:25 ` Peter Xu
2025-05-28 15:29 ` David Hildenbrand
2025-05-28 16:06 ` Peter Xu
2025-05-28 16:29 ` Jason Gunthorpe
2025-05-28 17:14 ` Peter Xu
2025-05-28 17:34 ` Jason Gunthorpe
2025-05-28 17:37 ` David Hildenbrand
2025-05-28 17:32 ` David Hildenbrand
2025-05-28 17:47 ` Jason Gunthorpe
2025-05-28 17:59 ` Jason Gunthorpe
2025-05-28 18:03 ` David Hildenbrand
2025-05-28 18:00 ` David Hildenbrand
2025-05-28 18:15 ` Jason Gunthorpe [this message]
2025-05-28 18:22 ` David Hildenbrand
2025-05-28 18:29 ` Jason Gunthorpe
2025-05-30 10:04 ` David Hildenbrand
2025-05-28 12:13 ` Jinjiang Tu
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=20250528181506.GA192531@nvidia.com \
--to=jgg@nvidia.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=tujinjiang@huawei.com \
--cc=vbabka@suse.cz \
--cc=wangkefeng.wang@huawei.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.