On 9/17/26 18:22, Lorenzo Stoakes (ARM) wrote:
> Commit e1fb4a086495 ("dax: remove VM_MIXEDMAP for fsdax and device dax")
> prevented fsdax and device-dax from setting VM_MIXEDMAP, as DAX no longer
> relies on it to direct core mm paths.
>
> The fuse DAX implementation, added later, copied the old pattern and still
> sets it.
>
> Fuse DAX maps pages the same way fsdax does, via dax_iomap_fault() and
> ultimately vmf_insert_page_mkwrite() and vmf_insert_folio_pmd(), which
> insert ordinary refcounted pages and so do not require VM_MIXEDMAP.
>
> Setting it only serves to mark the mapping as kernel-owned, making fuse DAX
> the sole DAX implementation whose mappings are unmergeable, cannot be
> mlock()'d, eagerly copy page tables on fork and reject MADV_DOFORK and
> MADV_DODUMP.
>
> It also requires vma_is_special_huge() in mm/huge_memory.c to carve DAX out
> of its kernel-owned check explicitly.
>
> There is no reason for fuse DAX to keep on using this flag so drop it.
>
> Signed-off-by: Lorenzo Stoakes (ARM) <[email protected]>
> ---
> fs/fuse/dax.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/fuse/dax.c b/fs/fuse/dax.c
> index 85cdf0199bc0..a5994f1c637d 100644
> --- a/fs/fuse/dax.c
> +++ b/fs/fuse/dax.c
> @@ -826,7 +826,7 @@ int fuse_dax_mmap(struct file *file, struct
> vm_area_struct *vma)
> {
> file_accessed(file);
> vma->vm_ops = &fuse_dax_vm_ops;
> - vm_flags_set(vma, VM_MIXEDMAP | VM_HUGEPAGE);
> + vma_set_flags(vma, VMA_HUGEPAGE_BIT);
Yes, I think I stumbled over that in the past as well:
Acked-by: David Hildenbrand (Arm) <[email protected]>
--
Cheers,
David
