From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Paolo Bonzini <pbonzini@redhat.com>,
linux-kernel@vger.kernel.org, kvm@vger.kernel.org
Cc: Boris Brezillon <boris.brezillon@collabora.com>,
Thomas Zimmermann <tzimmermann@suse.de>,
Michal Hocko <mhocko@suse.com>, Sergio Lopez <slp@redhat.com>,
Christian Koenig <christian.koenig@amd.com>,
Huang Rui <ray.huang@amd.com>,
bcm-kernel-feedback-list@broadcom.com,
dri-devel@lists.freedesktop.org, linux-mm@kvack.org
Subject: Re: [PATCH RFT 0/3] mm, drm: ensure .fault() does not have to be followed by .pfn_mkwrite() for write faults
Date: Mon, 3 Aug 2026 13:54:55 +0200 [thread overview]
Message-ID: <8d94897f-0f56-4ecf-bcc8-50bffd6750b2@kernel.org> (raw)
In-Reply-To: <20260731164341.1109827-1-pbonzini@redhat.com>
On 7/31/26 18:43, Paolo Bonzini wrote:
> Warning - DRM parts (i.e. most of the patches) untested; I have Cc'd
> the reporter to help with testing these patches.
>
> Right now, users of .pfn_mkwrite() have no way to create a PTE
> that has gone through maybe_mkwrite(). Because vma_set_page_prot()
> will have cleared the writable PTE bit, users of fixup_user_fault()
> will see a read-only PTE and have no clue that the page needs
> a *second* fault to reach its final status.
>
> Handling this in fixup_user_fault() is problematic: the information
> about the presence of *_mkwrite is only recorded in vma->vm_page_prot,
> which is an opaque pgprot_t, therefore only follow_pfnmap_start()
> knows how to retrieve it.
How is mprotect() supposed to work in that case?
--
Cheers,
David
next prev parent reply other threads:[~2026-08-03 11:55 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 16:43 [PATCH RFT 0/3] mm, drm: ensure .fault() does not have to be followed by .pfn_mkwrite() for write faults Paolo Bonzini
2026-07-31 16:43 ` [PATCH RFT 1/3] mm: export variants of vmf_insert_pfn* for use with pfn_mkwrite() Paolo Bonzini
2026-08-03 12:16 ` David Hildenbrand (Arm)
2026-08-04 13:52 ` Christoph Hellwig
2026-08-04 14:35 ` Paolo Bonzini
2026-07-31 16:43 ` [PATCH RFT 2/3] drm/shmem_helper: use vmf_insert_pfn_mkwrite() Paolo Bonzini
2026-07-31 17:06 ` sashiko-bot
2026-08-03 9:55 ` Boris Brezillon
2026-07-31 16:43 ` [PATCH RFT 3/3] drm/ttm, drm/vmwgfx: directly create writable PTEs when mkwrite is in use Paolo Bonzini
2026-07-31 17:04 ` sashiko-bot
2026-08-03 7:30 ` [PATCH RFT 0/3] mm, drm: ensure .fault() does not have to be followed by .pfn_mkwrite() for write faults Sergio Lopez Pascual
2026-08-03 11:54 ` David Hildenbrand (Arm) [this message]
2026-08-03 14:19 ` Paolo Bonzini
2026-08-03 15:18 ` David Hildenbrand (Arm)
2026-08-04 7:50 ` Paolo Bonzini
2026-08-04 12:19 ` David Hildenbrand (Arm)
2026-08-03 16:52 ` Paolo Bonzini
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=8d94897f-0f56-4ecf-bcc8-50bffd6750b2@kernel.org \
--to=david@kernel.org \
--cc=bcm-kernel-feedback-list@broadcom.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=pbonzini@redhat.com \
--cc=ray.huang@amd.com \
--cc=slp@redhat.com \
--cc=tzimmermann@suse.de \
/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.