Re: [PATCH v2 01/40] mm/vma: fix mmap_prepare file handling, remove file_doesnt_need_get
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Date: 2026-09-18 13:21:10
Also in:
bpf, fuse-devel, kvm, kvm-riscv, kvmarm, linux-arch, linux-doc, linux-fbdev, linux-fsdevel, linux-mm, linux-perf-users, linux-rdma, linux-s390, linux-scsi, linux-sound, linux-trace-kernel, linux-usb, lkml, selinux, sparclinux
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:quoted
On Mon, Sep 14, 2026 at 03:57:21PM +0100, Lorenzo Stoakes (ARM) wrote:quoted
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 (local) 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/ (local) -- Cheers, Lorenzo