Re: [PATCH v2 00/40] mm: make VMA flag semantics explicit, eliminate VM_SPECIAL

[Lorenzo Stoakes (ARM)]

[excise cc- list to mm]

On Mon, Sep 14, 2026 at 06:08:11PM -0700, Andrew Morton wrote:
> On Mon, 14 Sep 2026 15:57:20 +0100 "Lorenzo Stoakes (ARM)" <ljs@xxxxxxxxxx> wrote:
>
> > The VM_SPECIAL / VMA_SPECIAL_FLAGS mask conflates several unrelated
> > properties:
> >
> > ...
> >
> > It's all rather a mess.
> >
> > This series brings some order to things by both limiting what drivers can
> > do with VMA flags and switching to using predicates that describe
> > behaviour, not arbitrary flags.
>
> That's a lot of patches.

Yeah I know :)

I held this back from last cycle to reduce workload, but I can't keep doing
that :))

It's a lot but each patch is relatively easy to review.

>
> Review is thin and I expect this won't improve a lot.  Lots of "no
> functional changes" changes.

Well, I think it will! Had a meeting last night where Suren committed to
going through, and I will nag people.

It's a very busy cycle I realise but this is mostly fairly straight-forward
to review.

>
> Perhaps it would be helpful if you were to identify those patches which
> you'd like to see reviewers focus on?

The mlock stuff is probably the most sensitive bit. But in general that the
semantics are what we want.

Already had some review on the driver-specific bits from relevant people (I
fixup a bunch as part of the changes)

>
> >  1153 insertions(+), 582 deletions(-)
>
> It's funny how often cleanup patches do this.

Well it's not just a cleanup per se actually, I add a whole new
mmap_prepare() action methodology and add a bunch of mmap hook validation
so it's adding functionality to the kernel.

And there's a bunch of kdoc documentation too (plus a whole bunch of
additional _actual_ documentation added to the mmap_prepare doc page), so
there's good reason for the additions :>)

>
> All queued up, thanks.

Thanks!

--
Cheers, Lorenzo