Re: [PATCH v3 24/40] mm/mlock: eliminate weird VMA_IO_BIT abuse and simplify
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Date: 2026-09-25 09:35:32
Also in:
bpf, fuse-devel, kvm, kvm-riscv, kvmarm, linux-arch, linux-doc, linux-fbdev, linux-fsdevel, linux-mm, linux-perf-users, linux-rdma, linux-riscv, linux-s390, linux-scsi, linux-sound, linux-trace-kernel, linux-usb, lkml, selinux, sparclinux
On Thu, Sep 24, 2026 at 11:50:14AM -0400, Zi Yan wrote:
On 24 Sep 2026, at 6:21, Lorenzo Stoakes (ARM) wrote:
quoted
quoted
quoted
diff --git a/mm/folio.c b/mm/folio.c
index 47a437e0f7fd..35e242b48870 100644
--- a/mm/folio.c
+++ b/mm/folio.c
@@ -505,7 +505,7 @@ void folio_add_lru_vma(struct folio *folio, struct vm_area_struct *vma)
{
VM_BUG_ON_FOLIO(folio_test_lru(folio), folio);
- if (unlikely((vma->vm_flags & (VM_LOCKED | VM_SPECIAL)) == VM_LOCKED))
+ if (vma_test(vma, VMA_LOCKED_BIT))
I think it is worth documenting VMA_LOCKONFAULT_BIT alone means mlock in
progress, like you did in munlock_vma_folio(). Just to keep the protocol
explicit for all the readers.
Well I'm not sure it's necessary here honestly, because this never checked
VMA_LOCKED_MASK anyway, and VMA_LOCKONFAULT_BIT never made a difference.
So the meaning of VMA_LOCKED_BIT here is strictly 'is it locked' and it's
correctly handled.
And I fear that it becomes whack-a-mole - the neat thing about this change is
that you no longer have to special case the stupid VM_SPECIAL thing, and can in
fact do the 'normal' thing of _just checking_ VMA_LOCKED_BIT :)
So I think it's better not to.
Your reasoning makes sense to me.
Thanks :)
quoted
quoted
Why I am commenting in the middle of the series? Because I am taking
a quiz given by LLM based on this series to get myself enough background
knowledge to review this series. This mlock part came up at part E
and I only have part F left before I can do the full review. :)
Thanks! :) I really appreciate you taking the time to look at this! Sorry it's
so large.
Sure. It is great learning material for me. Thank you for the patches.
No worries, and sorry for the size of this change...! :)
quoted
I held this series back from last cycle to help with review load, then spent
some time fixing various AI-discovered things, and all the patches are necessary
(well for the most part) to get where the series needs to go.
I think the change is worth it though!
Of course, great to see hacky code being removed by this series.
For this patch, feel free to add
Reviewed-by: Zi Yan <ziy@nvidia.com>
Thanks :)
Best Regards,
Yan, Zi
--
Cheers, Lorenzo