Re: [PATCH] mm: prevent droppable mappings from being locked

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

On 3/10/26 03:04, anthony.yznaga@oracle.com wrote:
> 
> On 3/9/26 7:15 AM, David Hildenbrand (Arm) wrote:
>> On 3/6/26 21:45, Anthony Yznaga wrote:
>>> Mappings created with MAP_DROPPABLE cannot be locked via mlock() due
>>> to the check in mlock_fixup(). However, they will be locked indirectly
>>> if they are created after mlockall(MCL_FUTURE).
>>>
>>> Fixes: 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always
>>> lazily freeable mappings")
>>> Signed-off-by: Anthony Yznaga <anthony.yznaga@oracle.com>
>>> ---
>>>   include/linux/mm.h | 3 +++
>>>   mm/mlock.c         | 4 ++--
>>>   mm/vma.c           | 2 +-
>>>   3 files changed, 6 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index 5be3d8a8f806..bb830574d112 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -574,6 +574,9 @@ enum {
>>>   /* This mask represents all the VMA flag bits used by mlock */
>>>   #define VM_LOCKED_MASK    (VM_LOCKED | VM_LOCKONFAULT)
>>>   +/* This mask prevents VMAs from being mlock'd */
>>> +#define VM_NO_MLOCK_MASK    (VM_SPECIAL | VM_DROPPABLE)
>> Instead of adding that, could we cleanup further by doing something
>> like the following?
>>
>> The usage of "vma->vm_mm" must be double checked,
> 
> This sent me down an interesting rabbit hole since gate_vma->vm_mm is
> initialized to NULL. I can't see how the gate VMA could ever be passed
> to mlock_fixup() or __mmap_complete() if it's not part of the VMA tree
> of an mm and is not mapped through mmap. 

Right, gate_vma() would be shared across all processes.

Wouldn't code like the following be questionable as well?

fs/coredump.c:  if (vma == get_gate_vma(vma->vm_mm))
mm/vmscan.c:    if (vma == get_gate_vma(vma->vm_mm))


I mean, that cannot possibly be true unless I am missing something.

There are a couple of other
> places in the kernel that assume the gate VMA may be encountered when
> iterating VMAs, too. Am I missing something? Happy to clean these up if
> it makes sense.

Yes, please look into that. As an alternative, we could maybe pass
current->mm to get_gate_vma() ... but it'd be best to just clean that up.

-- 
Cheers,

David