Re: [PATCH 00/13] mm: continue vma_flags_t conversion

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Nov 06, 2026 at 03:35:01PM +0100, David Hildenbrand (Arm) wrote:
> I agree that this should be picked separately. For example, I will pick
> everything that falls into my realm to reduce conflicts.

Hmm, generally tree-wide mechanical changes are the exception to that rule
no?

It's going to make the rest of the VMA flags/mmap_prepare conversion really
quite difficult if I have to chase every single driver maintainer in the
kernel (literally in both cases pretty much :).

And sometimes there are dependencies which mean you really can't split it
across trees unless you establish functionality in one cycle and callers in
another, but that seems a little silly.

I was thinking that once the VMA tree is separate I'd put mechanical
changes like this through it. Is that not the way to go?

>
> Ideally, patches really only touch one component.

Right, but sometimes functions are declared in one place and called in
others. It is impossible to change the signature of one without also touching
the others.

>
> [PATCH 07/13] mm/madvise: convert madvise_vma_behavior() to use vma_flags_t
>
> is all over the place :)

It's not really all over the place, it's converting vm_flags_t to
vma_flags_t across madvise.c, which involves changing a few function
signatures, whose callers must be updated.

I could split it up into 3 patches where 1 does internal-only, one changes 1
function, and the next changes another, if that works?

But there's no way for that change to only touch madvise() given the
function decl/callers.

--
Cheers, Lorenzo