On Wed, 11 Mar 2026 10:36:26 +0000 "Lorenzo Stoakes (Oracle)" <[email protected]>
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.
You know what I'm going to ask ;)
Why backport this? What effect does/might the bug have upon our users?
