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

[David Hildenbrand (Arm)]

On 11/6/26 16:22, Lorenzo Stoakes (ARM) wrote:
> 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?

I think it really depends. If changes are well standalone, I don't see why it
couldn't just cleanly go through separate trees.

Anything that is more involved (like the madvise change), there is not really a
way around.

Well, there is: stable topic branch and letting separate trees merge that ...

> 
> 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?

Maybe? We'll have to learn. Right now it immediately caused conflicts between
mine and Andrew's tree.

Because of [PATCH 05/13] mm: convert THP VMA flag tests to use vma_flags_t which
is THP-only, and feels like it could go straight through one of my trees,
avoiding conflicts with Andrew's tree. But maybe there is more to it that I am
missing.

I assume stable topic branches would fix that, but they are currently
unfortunately not on the table ... :)

> 
>>
>> 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.

Yes. Something like that is unavoidable. Or if you need new APIs/

> 
>>
>> [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.

Ah, yeah. What on earth does arch/powerpc/kvm/book3s_hv_uvmem.c do with madvise :(

> 
> 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?

No, these things really have to go in as one unit, no need to split that up.

-- 
Cheers,

David