On 11/6/26 16:22, Lorenzo Stoakes (ARM) wrote:
On Fri, Nov 06, 2026 at 03:35:01PM +0100, David Hildenbrand (Arm) wrote:
quoted
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 :).
quoted
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 ... :)
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/
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 :(
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