On Mon, Jul 17, 2023 at 5:54 PM Yan Zhao <yan.y.zhao@xxxxxxxxx> wrote: > > On Mon, Jul 17, 2023 at 09:18:34AM -0700, Suren Baghdasaryan wrote: > > On Sun, Jul 16, 2023 at 11:40 PM Yan Zhao <yan.y.zhao@xxxxxxxxx> wrote: > > > > > > On Wed, Jul 12, 2023 at 07:48:06PM +0000, Suren Baghdasaryan wrote: > > > > > Would we be able to fix it in stable simply by not triggering the > > > > > vm_flags_set() in case these flags are already set? > > > > > > > > I think we can do that. gru_file_mmap() sets all the flags that are > > > > set by remap_pfn_range_notrack() (VM_IO | VM_PFNMAP | VM_DONTEXPAND | > > > > VM_DONTDUMP), so we can check if all bits are already present and skip > > > > the vm_flags_set() call. > > > > > > > But on x86, remap_pfn_range() also sets flag VM_PAT. (in track_pfn_remap()). > > > > > > Is there any interface to allow device driver to pre-set this flag in .mmap() > > > before .fault()? e.g. export track_pfn_remap() ? > > > > Driver should be able to call vm_flags_set() in its .mmap(). > > Do you mean do something like this in .mmap()? > > flags = VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; > #ifdef CONFIG_X86 > flags |= VM_PAT; > #endif > vm_flags_set(vma, flags); > > But VM_PAT cannot be set until after a successful reserve_pfn_range(), > which function is again not exported. I see. Let's wait for Matthew's fix and see what it looks like first. Maybe we can backport it directly instead of using alternatives.
