Conditions for FOLL_LONGTERM mapping in fsdax

Commit Message

Usama Arif Nov. 6, 2023, 6:13 p.m. UTC

Hi,

We wanted to run a VM with a vfio device assigned to it and with its 
memory-backend-file residing in a persistent memory using fsdax (mounted 
as ext4). It doesnt currently work with the kernel as 
vfio_pin_pages_remote ends up requesting pages with FOLL_LONGTERM which 
is currently not supported. From reading the mailing list, what I 
understood was that this is to do with not having DMA supported on fsdax 
due to issues that come up during truncate/hole-punching. But it was 
solved with [1] by deferring fallocate(), truncate() on a dax mode file 
while any page/block in the file is under active DMA.

If I remove the check which fails the gup opertion with the below diff, 
the VM boots and the vfio device works without any issues. If I try to 
truncate the mem file in fsdax, I can see that the truncate command gets 
deferred (waits in ext4_break_layouts) and the vfio device keeps working 
and sending packets without any issues. Just wanted to check what is 
missing to allow FOLL_LONGTERM gup operations with fsdax? Is it just 
enough to remove the check? Thanks!




[1] 
https://lore.kernel.org/all/[e-mail]/

Regards,
Usama

Patch

diff --git a/mm/gup.c b/mm/gup.c
index eb8d7baf9e4d..f77bb428cf9b 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -1055,9 +1055,6 @@  static int check_vma_flags(struct vm_area_struct 
*vma, unsigned long gup_flags)
         if (gup_flags & FOLL_ANON && !vma_is_anonymous(vma))
                 return -EFAULT;

-       if ((gup_flags & FOLL_LONGTERM) && vma_is_fsdax(vma))
-               return -EOPNOTSUPP;
-
         if (vma_is_secretmem(vma))
                 return -EFAULT;