From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9708E3B893E for ; Mon, 9 Mar 2026 14:28:11 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773066491; cv=none; b=kAgP3tug57IwS76rw2aODJjGIkNa+dZdQXI5NbZIJKaqwIe0QTJjEvUR3KW36eUfm9f0VwDNRCyl7+CXbFS4aAmOI5A7xdvP1u3vfZGC9OgxzS4NwxnWVRbcws028AaM2a1r1SdheBcoM7X3fFX4KGL2GJi2ChOYf4slkQN7CQI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773066491; c=relaxed/simple; bh=7JXNJOMUJUG51xw/lDjwV9j46CypKr82OtNBQJLLoIA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=dfBLE0Z8bu0nQgZEW7S/CKjuFmk0uFOPGwBMo4mzBId+ujQ6J37UOV9I81IE5ww50qfoUavSZhip25ziiNld1DZZ83AKcL9g81Yp5C1V9CsZRa1qEuNKi7DVufyTCbSCVYPraiHC0oVKXtmEP6GnMTWvP1G0v/wnLjaVdXUMYgE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tG/pGiO9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tG/pGiO9" Received: by smtp.kernel.org (Postfix) with ESMTPSA id D8B8AC2BC86; Mon, 9 Mar 2026 14:28:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773066491; bh=7JXNJOMUJUG51xw/lDjwV9j46CypKr82OtNBQJLLoIA=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tG/pGiO9hnbZk88Ow8KejU1Q2MK/j8Kkjr8IKz2pY4rbEyoaI9DzUa/4Xie4bC7RE blTU3l3ZiLIQdn8aeVnObkUGo8IIiOyVtIum+na+R6a7kUzjgrYL+xhDCXOicSZCYP ZvQpm0qw3Jf1RfR7ie9o9rdkx5hO6B/fDBjGT/PGT014CE6sI6zvtMHmioj+yVJyWU cWhpH+xM3soBg1ykGQ6gJvQiMR3ZI28h6VxqYu0WzNzccGi2csXDTtra9DPOQhbiz2 fFJTdLMtVJ8G6OeVXtDnQEm7o+UOE63aFUrKRZ7zNMyCKl9OR1BEisTOs38rbXD5aY 0mB+HD5syWjGw== Date: Mon, 9 Mar 2026 14:28:08 +0000 From: "Lorenzo Stoakes (Oracle)" To: Anthony Yznaga Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, david@kernel.org, Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, jannh@google.com, pfalcato@suse.de, Jason@zx2c4.com Subject: Re: [PATCH] mm: prevent droppable mappings from being locked Message-ID: <53d66564-0596-45aa-b639-e2ea15356ae9@lucifer.local> References: <20260306204550.8405-1-anthony.yznaga@oracle.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260306204550.8405-1-anthony.yznaga@oracle.com> -cc old mail (this is going to take some time to propagate I realise :P) On Fri, Mar 06, 2026 at 12:45:50PM -0800, 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). You need to add more details here. For e.g.: '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. Therefore, in __mmap_complete(), extend the test for VM_SPECIAL to include a test for VM_DROPPABLE'. Do you have a test that can check for this? It'd be good to have a regression test to assert that it now behaves correctly. You could extend either tools/testing/selftests/mm/mlock2-tests.c or droppable.c? It's worth mentioning that mlockall(MCL_ONFAULT) is handled too, as VM_LOCKONFAULT is always set with VM_LOCKED (the only difference being that, when trying to fault in memory for VM_LOCKED ranges, gup exits early in populate_vma_page_range() which has an explicit test for VM_LOCKONFAULT) , and apply_mlockall_flags() will invoke mlock_fixup() which already has the VM_DROPPABLE check. > > Fixes: 9651fcedf7b9 ("mm: add MAP_DROPPABLE for designating always lazily freeable mappings") Do we want to cc: stable here? > Signed-off-by: Anthony Yznaga > --- > 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) > + It'd be preferable to not use the legacy VMA flags implementation, but if we're backporting I guess... However there's only one place you need to update, the other already manually checks droppable, and it'd make my life easier for the VMA flags conversions to not define a flag like this also :) > /* These flags can be updated atomically via VMA/mmap read lock. */ > #define VM_ATOMIC_SET_ALLOWED VM_MAYBE_GUARD > > diff --git a/mm/mlock.c b/mm/mlock.c > index 2f699c3497a5..fd35c1e88c4c 100644 > --- a/mm/mlock.c > +++ b/mm/mlock.c > @@ -472,9 +472,9 @@ static int mlock_fixup(struct vma_iterator *vmi, struct vm_area_struct *vma, > int ret = 0; > vm_flags_t oldflags = vma->vm_flags; > > - if (newflags == oldflags || (oldflags & VM_SPECIAL) || > + if (newflags == oldflags || (oldflags & VM_NO_MLOCK_MASK) || > is_vm_hugetlb_page(vma) || vma == get_gate_vma(current->mm) || > - vma_is_dax(vma) || vma_is_secretmem(vma) || (oldflags & VM_DROPPABLE)) > + vma_is_dax(vma) || vma_is_secretmem(vma)) This obviously wouldn't be necessary without adding a new VM_xxx... > /* don't set VM_LOCKED or VM_LOCKONFAULT and don't count */ > goto out; > > diff --git a/mm/vma.c b/mm/vma.c > index be64f781a3aa..1334622e4a03 100644 > --- a/mm/vma.c > +++ b/mm/vma.c > @@ -2589,7 +2589,7 @@ static void __mmap_complete(struct mmap_state *map, struct vm_area_struct *vma) > > vm_stat_account(mm, vma->vm_flags, map->pglen); > if (vm_flags & VM_LOCKED) { > - if ((vm_flags & VM_SPECIAL) || vma_is_dax(vma) || > + if ((vm_flags & VM_NO_MLOCK_MASK) || vma_is_dax(vma) || For backport maybe just put an additional vm_flags & VM_DROPPABLE here? > is_vm_hugetlb_page(vma) || > vma == get_gate_vma(mm)) > vm_flags_clear(vma, VM_LOCKED_MASK); > -- > 2.47.3 > Though I saw David suggested something different so that also addresses my review here :) Cheers, Lorenzo