[Update] mm-next status 2026/07/13

[Update] mm-next status 2026/07/13

[David Hildenbrand (Arm)]

Hi,

a status update about the MM transition [1] after we had two bi-weekly mm-next
calls.

I'm sure I'll mess something up, so hopefully people will correct me where I'm
wrong or when I am missing something important.


1) Tree/branch Locations
------------------------

We discussed which tress we'll have and where they will be located. Tress will
be listed in the MAINTAINERS file. After some discussions, we agreed on the
following:

The mm-next tree for the mm-next maintainer(s)/backups will be located at:

	https://git.kernel.org/pub/scm/linux/kernel/git/mm/linux.git/

For all components that we separate out and let component owners take care of
picking patches (initially memblock and slab), the trees will be located at /
moved to:

	https://git.kernel.org/pub/scm/linux/kernel/git/mm/$component.git/

Component maintainers will not have write access to other component trees /
mm-next tree.


2) mm/linux.git ("mm-next") Branches
------------------------------------

We discussed which branches the mm-next tree will need, and decided on the
following for now:

for-next-fixes:
 -> Integrates all component “for-next-fixes” branches
 -> Goes to linux-next.git pending-fixes

for-next:
 -> Integrates all component “for-next-fixes” + “for-next” branches
 -> Goes to linux-next.git master

for-test: (TBD, deferred for now)
 -> Similar to current mm-new, will not go to linux-next.git
 -> TBD if and how we'll use it.

for-linus: (TBD)
 -> Only used for building PULL requests.
 -> Might not really be required.

$component/*
 -> Patch management for branches while maintained by mm-next maintainer(s)
 -> Will be moved out once dedicated component maintainers take over


All integration trees are rebuild constantly by merging other branches, similar
to -next. Commit IDs will be stable as long as they remain stable from the
source branch they are getting merged from.


3) mm/$component.git Branches
-----------------------------

We discussed which branches component trees will need for integration into
mm-next, and how the branches will be managed,  and decided on the following for
now:

Similar structure as mm-next:

for-next-fixes:
 -> Integrated into mm/linux.git for-next-fixes

for-next:
 -> Integrated into mm/linux.git for-next

for-test: (TBD, deferred for now)
 -> Integrated into mm/linux.git for-test

+ other topic branches as required


These branches are not necessarily used for creating PULL requests. Commits that
will go upstream need a stable commit ID in the for-next* branches for some time
(e.g., fixes 1 week, features > 2 weeks).

How these branches are managed is up to component maintainers. There are various
options:

a) Have the branches with stable followed by unstable commits. Never rebase such
   that stable commits would change. Good enough for very little activity.

b) Have stable+unstable branches that are integrated (i.e., merged) into the
   for-next* branches.

c) Use actual topic branches that are integrated (i.e., merged) into the for-
   next* branches.

d) Do something like VFS with versioned branch names ... that are integrated
   (i.e., merged) into the for-next* branches.


5) AKPM integration
-------------------

We discussed how we will integrate Andrews trees during the transition.

mm-hotfixes-unstable (which includes mm-hotfixes-stable) will be integrated into
mm/linux.git for-next-fixes.

mm-stable + mm-unstable + mm-hotfixes-unstable will be integrated into
mm/linux.git for-next: similar to how linux-next.git integrates it today.

The expectation is, that once more components are maintained in
https://git.kernel.org/pub/scm/linux/kernel/git/mm/*, the smaller Andrews MM
tree will get.

Conflict management TBD, and to be learned as we move forward.


5) PULL Request Handling
------------------------

So far we touched on that topic a couple of times, but did not decide on it finally.

At this point, it seems like something similar to the KVM model (components
sending PULL requests to mm-next maintainer, which bundles (selected) PULL
requests and sends the to Linus) might make most sense.


6) MM CI
--------

Mike presented the current github-based CI that is based on the BPF workflow:
* A bot grabs new submissions from patchwork (IIUC) and tries to apply it on top
  of selected known branches (e.g., mm-unstable)
* Creates a github MR for that submission and triggers the CI ...
* ... which compiles a kernel, to boot it in a VM and runs MM selftests +
  memblock, vma, xarray, mable tree etc. tests
* Reflects the status in patchwork

We discussed that we need more CI runners. So far we primarily have x86-64-based
ones. David tries to get some arm64 runners, maybe some other companies can jump
in as well. There was the idea of using some of BPFs infrastructure, as BPF does
not fully exhaust their capacity.

We also discussed that the selftests need more care (e.g., stability, test
coverage), and that performance tests are out of scope for now. Arm has likely
some capacity to work on improving selftests.

We also talked about advanced tests, in particular performance tests, and agreed
that we'll likely need a separate test project that bundles performance tests in
the future.

The primary motivation for the CI is to make it easier to judge whether a patch
set is worth applying, reducing manual build+tests for component maintainers.

So far, no CI mails are sent out yet, but we might decide to change that in the
future.


7) Next Steps
-------------

* Start setting up mm-next branches and get the merge process flowing.
* Exercise the model with memblock and slab.
* Once working reliably, ask for a -next integration change, dropping Andrew's
  MM tress + slab and memblock trees.
* Start picking patches for smaller, well-isolated components into the mm-next
  tree and see how that integrates.


8) Topics to Discuss Next
-------------------------

What we'll cover in the next session will likely be around:

* PULL request handling
* Component branch handling rules
* Hotfixes process
* Against which branches to submit patches

Further, we'll also talk, more generally, about AI review in the context of mm-next.


There are still plenty of things to figure out. If you feel like you should be
part of the discussions and were missed so far, please let me known and I can
add you to the meeting invitation.


[1]
https://lore.kernel.org/linux-mm/3166fcdd-5f08-4f7c-a743-192d0e0207d1@kernel.org/

-- 
Cheers,

David