Re: [PATCH v2 01/40] mm/vma: fix mmap_prepare file handling, remove file_doesnt_need_get

[Breno Leitao <leitao@debian.org>]

On Fri, Sep 18, 2026 at 02:20:34PM +0100, Lorenzo Stoakes (ARM) wrote:
> On Fri, Sep 18, 2026 at 05:57:51AM -0700, Breno Leitao wrote:
> > On Thu, Sep 17, 2026 at 12:33:41PM +0300, Mike Rapoport wrote:
> > > On Mon, Sep 14, 2026 at 03:57:21PM +0100, Lorenzo Stoakes (ARM) wrote:
> > > > The map->file_doesnt_need_get flag is confusing and the existing
> > > > implementation has holes.
> > > >
> > > > Drivers are permitted to change the owning file of a mapping. If they do
> > > > so, they are required to take a reference on that file.
> > > >
> > > > The mmap() operation which ultimately invokes __mmap_region() is guaranteed
> > > > to drop the refcount for the original file the mapping was made under, but
> > > > this is not true for the replaced file.
> > > >
> > > > This has been addressed so far by tracking map->file_doesnt_need_get, which
> > > > is rather poorly named and unfortunately fails to correctly track whether
> > > > or not an additional put were needed in a number of cases.
> > > >
> > > > Make life easier by removing this flag, and instead drop the reference for
> > > > both mmap_prepare and the deprecated mmap callback in a new function
> > > > put_map().
> > > >
> > > > Track whether this needs to be done by aligning mmap_state with
> > > > vm_area_desc and store the original file in the map->file field, keeping
> > > > the updated file in map->vm_file.
> > > >
> > > > In order to have the same behaviour for both types of hooks, only drop the
> > > > reference __mmap_new_file_vma() itself took in its error path, deferring
> > > > the replaced file's reference to put_map().
> > > >
> > > > To make this work correctly, map->vm_file has to be updated before any
> > > > error handling, so update __mmap_new_file_vma() and call_mmap_prepare() to
> > > > set this field first.
> > > >
> > > > Also when mmap_prepare() changes the file and is then merged, the reference
> > > > count also must be decremented, so update the logic to call put_map() in
> > > > this case too.
> > > >
> > > > Also update __compat_vma_mmap() to manually perform this step for stacked
> > > > file systems using the compatibility layer, and update
> > > > compat_set_vma_from_desc() to replace vma_set_file() with a correct
> > > > refcount/file update.
> > > >
> > > > No in-tree driver is impacted by the incorrect implementation of this
> > > > currently (no driver that does this is mergeable for one), so this does not
> > > > need to be a fix.
> > >
> > > But the patch iteslf needs to be fixed :)
> > >
> > > It seems to be the change that broke the CI.
> > >
> > > The rest is from LLM, take it with a grain of salt :)
> > >
> > > mm-ci mm-unstable red build - bisect analysis
> > > ==============================================
> > >
> > > Bad commit: 2a937a04babf1 "mm/vma: fix mmap_prepare file handling, remove
> > > file_doesnt_need_get" - first patch of Lorenzo Stoakes' 40-patch series
> > > "mm: make VMA flag semantics explicit, eliminate VM_SPECIAL" (v2).
> > > https://lore.kernel.org/all/20260914-b4-mmap-prepare-vma-flag-sanify-v2-0-7d9781ed5361@kernel.org
> > >
> > > Symptom: tools/testing/selftests/mm/pfnmap.c triggers
> > > "BUG: Bad page map in process pfnmap" during __zap_vma_range()/vm_normal_page(),
> > > seen on process exit/munmap. CI's run-mm-selftests.sh greps guest dmesg for
> > > BUG|WARNING and fails the job regardless of the test's own exit code.
> >
> > I am seeing something similar here and stress-ng can reproduce it:
> >
> >       WARNING: mm/memory.c:3225 at do_remap_pfn_range+0x9b4/0x9f0, CPU#25: stress-ng-dev/354858
> >       Call trace:
> >        do_remap_pfn_range+0x9b4/0x9f0 (P)
> >        remap_pfn_range_complete+0xac/0xd0
> >        mmap_action_complete+0xcc/0x3d8
> >        mmap_region+0xb54/0x1978
> >        do_mmap+0x588/0xb18
> >        vm_mmap_pgoff+0x1e4/0x320
> >        ksys_mmap_pgoff+0x2d8/0x510
> >        __arm64_sys_mmap+0x100/0x128
> >
> >       BUG: Bad page map in process stress-ng-dev  pte:0160000000000fcf
> >       addr:0000ffe8d9080000 vm_flags:00000071 anon_vma:0000000000000000 mapping:ffff0000a0c4ea98 index:0 (file) ffe8d9080 (anon)
> >       file:mem fault:0x0 mmap:0x0 mmap_prepare: mmap_mem_prepare read_folio:0x0
> >       Call trace:
> >        print_bad_page_map+0x63c/0x740
> >        vm_normal_page+0x228/0x240
> >        __zap_vma_range+0xbe0/0x34a0
> >        unmap_vmas+0x240/0x318
> >        unmap_region+0x12c/0x238
> >        vms_complete_munmap_vmas+0x318/0x958
> >        do_vmi_align_munmap+0x254/0x2f8
> >        do_vmi_munmap+0xc4/0xf8
> >        __vm_munmap+0x174/0x288
> >        __arm64_sys_munmap+0x70/0x90
> 
> Yup I already fixed it and respun the series :)
> 
> https://lore.kernel.org/all/20260917-b4-mmap-prepare-vma-flag-sanify-v3-0-4583d8a23bca@kernel.org/

Very nice, thanks. I will give it a try!