Re: Conditions for FOLL_LONGTERM mapping in fsdax

[Usama Arif <usama.arif@bytedance.com>]

On 06/11/2023 18:15, Usama Arif wrote:
> 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!
> 
> 
> 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;
> 
> 
> [1] 
> https://lore.kernel.org/all/152669371377.34337.10697370528066177062.stgit@dwillia2-desk3.amr.corp.intel.com/
> 

Hi,

Just wanted to check if there were any comments on this?

Thanks


> Regards,
> Usama