Re: [PATCH v2 1/2] mm: prevent droppable mappings from being locked

["David Hildenbrand (Arm)" <david@kernel.org>]

On 3/12/26 03:01, anthony.yznaga@oracle.com 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