All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.