Re: [PATCH v6 3/3] mm/gup: disallow FOLL_LONGTERM GUP-fast writing to file-backed mappings

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:

quoted

Am 02.05.23 um 01:11 schrieb Lorenzo Stoakes:

quoted

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