On Thu, Sep 24, 2026 at 11:50:14AM -0400, Zi Yan wrote:
> On 24 Sep 2026, at 6:21, Lorenzo Stoakes (ARM) wrote:
> >>> 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 :)
> >> 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...! :)
>
> >
> > 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 <[email protected]>
Thanks :)
>
>
>
> Best Regards,
> Yan, Zi
--
Cheers, Lorenzo
