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

[David Hildenbrand (Arm)]

On 11/7/26 21:09, Lorenzo Stoakes (ARM) wrote:
> I think we're slightly talking across purposes, so to be clear - I am totally
> fine with you taking any of this through your tree or whatever works for you and
> Andrew to avoid merge pain :)
> 
> I was just talking more generally about how to merge series that touch a lot of
> subsystems and maintainers-who-may-never-reply, etc.
> 
> These are the edge cases that make things... fun :)
> 
> Anyway, I guess easiest resolution here is for you to take the bits that belong
> to your trees and Andrew takes the bits that belong elsewhere?

Yes, that's what I did now, applying #1,#3,#4,#5,#6

7+8 touches some of my components, but the chance for conflicts are hopefully small.

> 
> I don't think anything here has an inter-dependency.
> 

Yeah that makes it a lot easier.

> 
> On Sat, Nov 07, 2026 at 08:26:29PM +0100, David Hildenbrand (Arm) wrote:
> [ ... ]
>>
>> 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.
> 
> Sorry about that! Please take that through your tree.
> 

Not your fault, I guess we'll have to get used to merging stuff through separate
trees, and dealing with conflicts that cannot be avoided :)

>>
>> I assume stable topic branches would fix that, but they are currently
>> unfortunately not on the table ... :)
> 
> I guess we need everybody-on-git for this!
> 
> I guess when Liam and & I have the VMA tree we can do that at least for stuff
> that goes there :)

Ack!

> 
>>
>>>
>>>
>>> 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/
> 
> Yes.
> 
>>
>>>
>>>
>>> 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 :(
> 
> Yeah it's quite worrying that... :)
> 
>>
>>>
>>> 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.
> 
> Thanks, yeah, it's a pain I know but eventually 'one fine day' (probably in
> 2028) everything will be converted to vma_flags_t/mmap_prepare and we won't have
> to think about this :P

Right! :)

-- 
Cheers,

David