On Tue, May 02, 2023 at 01:54:41PM +0100, Lorenzo Stoakes wrote: > On Tue, May 02, 2023 at 02:46:28PM +0200, Christian Borntraeger wrote: > > Am 02.05.23 um 01:11 schrieb Lorenzo Stoakes: > > > Writing to file-backed dirty-tracked mappings via GUP is inherently broken > > > as we cannot rule out folios being cleaned and then a GUP user writing to > > > them again and possibly marking them dirty unexpectedly. > > > > > > This is especially egregious for long-term mappings (as indicated by the > > > use of the FOLL_LONGTERM flag), so we disallow this case in GUP-fast as > > > we have already done in the slow path. > > > > Hmm, does this interfer with KVM on s390 and PCI interpretion of interrupt delivery? > > It would no longer work with file backed memory, correct? > > > > See > > arch/s390/kvm/pci.c > > > > kvm_s390_pci_aif_enable > > which does have > > FOLL_WRITE | FOLL_LONGTERM > > to > > > > Does this memory map a dirty-tracked file? It's kind of hard to dig into where > the address originates from without going through a ton of code. In worst case > if the fast code doesn't find a whitelist it'll fall back to slow path which > explicitly checks for dirty-tracked filesystem. This looks like the same stuff David was talking about, a qemu guest with VFIO backed by a filesystem file.. Broadly though, arch kvm code should not call pin_user_pages(). Either it is KVM focused and it should use the shadow table and it's existing mmu_notifier synchronization scheme Or it is VFIO focused so it should use mdev/etc and have an unmap call back. I'm not really sure what this is for though.. Jason
