On 3/12/26 03:01, [email protected] wrote: > > On 3/11/26 2:27 AM, David Hildenbrand (Arm) wrote: >> On 3/10/26 16:58, Anthony Yznaga wrote: >>> Droppable mappings must not be lockable. There is a check for VMAs with >>> VM_DROPPABLE set in mlock_fixup() along with checks for other types of >>> unlockable VMAs which ensures this when calling mlock()/mlock2(). >>> >>> For mlockall(MCL_FUTURE), the check for unlockable VMAs is different. >>> In apply_mlockall_flags(), if the flags parameter has MCL_FUTURE set, >>> the >>> current task's mm's default VMA flag field mm->def_flags has VM_LOCKED >>> applied to it. VM_LOCKONFAULT is also applied if MCL_ONFAULT is also >>> set. >>> When these flags are set as default in this manner they are cleared in >>> __mmap_complete() for new mappings that do not support mlock. A check >>> for >>> VM_DROPPABLE in __mmap_complete() is missing resulting in droppable >>> mappings created with VM_LOCKED set. To fix this and reduce that >>> chance of >>> similar bugs in the future, introduce and use vma_supports_mlock(). >>> >>> Fixes: 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always >>> lazily freeable mappings") >> Should we Cc: stable? I think we should, to fix mlockall(MCL_FUTURE) >> behavior. > > I found this issue through code inspection while doing mshare dev work. > I don't have a strong idea how likely it is to happen in practice. If it > did it might not be easily diagnosed so I'm fine adding the tag.
IIUC, mlockall(MCL_FUTURE) will result in future MAP_DROPPABLE mappings to get mlocked. I assume that implies that all pages will get faulted in and might not be reclaimable. With a quick test program that mmaps 4M, we indeed fault in all these pages (I assume you test does something similar). 7f5fc4600000-7f5fc4a00000 rw-p 00000000 00:00 0 Size: 4096 kB KernelPageSize: 4 kB MMUPageSize: 4 kB Rss: 4096 kB Pss: 4096 kB Pss_Dirty: 4096 kB Shared_Clean: 0 kB Shared_Dirty: 0 kB Private_Clean: 0 kB Private_Dirty: 4096 kB Referenced: 4096 kB Anonymous: 4096 kB KSM: 0 kB LazyFree: 0 kB AnonHugePages: 4096 kB ShmemPmdMapped: 0 kB FilePmdMapped: 0 kB Shared_Hugetlb: 0 kB Private_Hugetlb: 0 kB Swap: 0 kB SwapPss: 0 kB Locked: 4096 kB It's a good question whether memory reclaim would still be able to free these pages. I'd assume the folios would get mlocked and essentially turned unevictable -- breaking the whole concept of droppable mappings. So I think we should CC stable. -- Cheers, David
