On 3/12/26 03:16, [email protected] wrote: > > On 3/11/26 3:36 AM, Lorenzo Stoakes (Oracle) wrote: >> On Tue, Mar 10, 2026 at 08:58:20AM -0700, 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") >> We should definitely cc: stable I think. >> >> It might result in some backport pain since it'll probably pre-date the >> __mmap_region() stuff :)) sorry. > > I could add a patch at the beginning that does the cheap fix followed by > this patch.
Any backport conflicts should be easy and fast too resolve (if any). No need to uglify our mainline patches :) -- Cheers, David
