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 :)
quoted
quoted
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.
quoted
quoted
[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... :)
quoted
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