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? I don't think anything here has an inter-dependency. 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. > > 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 :) > > > > >> > >> 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/ Yes. > > > > >> > >> [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 :( 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 -- Cheers, Lorenzo
