Re: [PATCH v2 2/6] drm/shmem_helper: use vmf_insert_pfn_mkwrite()
Paolo Bonzini <[email protected]> Tue, 4 Aug 2026 16:34:10 +0200
| Newsgroups | gmane.comp.emulators.kvm.devel,gmane.linux.kernel,gmane.comp.video.dri.devel,gmane.linux.kernel.mm,gmane.linux.kernel.stable |
|---|---|
| Message-ID | <CABgObfbAveuhkjXzmemvGtycmcmDePKABr8Q35Y9mZP0den5aA@mail.gmail.com> |
On Tue, Aug 4, 2026 at 4:19=E2=80=AFPM Boris Brezillon <[email protected]> wrote: > On Tue, 4 Aug 2026 16:15:49 +0200 > Boris Brezillon <[email protected]> wrote: > > Actually, if we're making the drm_gem_shmem_record_mkwrite() call > > unconditional (for PTE and PMD updates) in that path, can't we drop the > > drm_gem_shmem_pfn_mkwrite() call living in drm_gem_shmem_pfn_mkwrite()? > > > > Also, I'm not even sure we can end up with write=3Dtrue for PTE updates= , > > because our pfn_mkwrite implementation returns zero, not VM_FAULT_ERROR > > or VM_FAULT_NOPAGE. This means the default RO -> RW PTE upgrade > > implemented in finish_mkwrite_fault() [1] will take place. If we really > > want out try_insert_pfn() to be called for those RO -> RW updgrades, we > > need to call try_insert_pfn() from drm_gem_shmem_pfn_mkwrite(). > > Nevermind, it's all explained in the comment you've added. Sorry for > the noise. I keep wondering if we shouldn't call try_insert_pfn() from > pfn_mkwrite() though, like is done in other places. No, the .pfn_mkwrite() callback is invoked when a PTE already exists, and mm/ already takes care of making it writable. So there's nothing to insert, you just have to take note which you do with drm_gem_shmem_record_mkwrite(). Paolo