Re: [PATCH 0/7] MAINTAINERS: MM updates

From: David Hildenbrand (Arm)

Date: Mon Nov 02 2026 - 01:50:48 EST


On 11/1/26 21:30, Andrew Morton wrote:
> On Sun, 1 Nov 2026 14:33:57 +0100 "David Hildenbrand (Arm)" <david@xxxxxxxxxx> wrote:
>
>> On 10/30/26 22:34, David Hildenbrand (Arm) wrote:
>>> Hi,
>>>
>>> several MM updates:
>>>
>>
>> @Andrew, should I pick these or do you want to route them through your tree?
>
> I'll grab for now, thanks. As a hotfix.
>
> Because I'm whacking away at MAINTAINERS at present. First step is to
> consistently name the components, below.
>
> This is a two-patch series. The first renames components so everything
> starts with "^MEMORY MANAGEMENT", leaving MAIINTAINERS incorrectly
> sorted. The second patch only moves things around, to restore the
> alphasorting.
>
> So people only need look at the first patch. Please review that.
>
> After this I'll have it identify the various files under include/linux,
> mm/ and lib/ which can fairly be described as "mm". That's looking
> like about 50 files at this time.

[...]

>
> Then I shall have it ensure that all these not-yet-covered files are
> entered in the appropriate place under an MM component. This may
> require creation of new components for the purpose, tbd.
>
> After that I needs to have it cover Documentation/
>
> After that I need to have it whack away at selftests, shudder.

I am not convinced yet that we want that for all tests, which is why I left it
out. There is too much churn that's not really relevant for a component
maintainer POV.

I was rather thinking that maybe we'd want a MM selftest component (likely for
the later MISC maintainer) that picks up the usual selftest churn. Component
maintainers really only have to be CCed on functional things.

>
>
>
> From: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> Subject: MAINTAINERS: use a common prefix for MM components
> Date: Sun, 01 Nov 2026 12:13:07 -0800
>
> Several MM component entries still use standalone headings, so searching
> for headings beginning with "MEMORY MANAGEMENT" misses them.
>
> Give these 18 entries the common "MEMORY MANAGEMENT - " prefix. Leave
> them in place for now so that the renames can be reviewed separately
> from the subsequent alphabetical sorting.
>
> Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
>
>
> ---
>
> MAINTAINERS | 36 ++++++++++++++++++------------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
>
> --- a/MAINTAINERS~maintainers-use-a-common-prefix-for-mm-components
> +++ a/MAINTAINERS
> @@ -6816,7 +6816,7 @@ T: git https://gitlab.freedesktop.org/dr
> F: include/linux/cgroup_dmem.h
> F: kernel/cgroup/dmem.c
>
> -CONTROL GROUP - MEMORY RESOURCE CONTROLLER (MEMCG)
> +MEMORY MANAGEMENT - MEMORY RESOURCE CONTROLLER (MEMCG)
> M: Johannes Weiner <hannes@xxxxxxxxxxx>
> M: Michal Hocko <mhocko@xxxxxxxxxx>
> M: Roman Gushchin <roman.gushchin@xxxxxxxxx>
> @@ -7322,7 +7322,7 @@ S: Maintained
> W: https://docs.dasharo.com/
> F: drivers/platform/x86/dasharo-acpi.c
>
> -DAMON
> +MEMORY MANAGEMENT - DAMON
> M: SJ Park <sj@xxxxxxxxxx>
> L: damon@xxxxxxxxxxxxxxx
> L: linux-mm@xxxxxxxxx
> @@ -12164,7 +12164,7 @@ S: Maintained
> F: Documentation/ABI/testing/debugfs-hisi-zip
> F: drivers/crypto/hisilicon/zip/
>
> -HMM - Heterogeneous Memory Management
> +MEMORY MANAGEMENT - HMM (Heterogeneous Memory Management)
> M: Jason Gunthorpe <jgg@xxxxxxxxxx>
> M: Leon Romanovsky <leonro@xxxxxxxxxx>
> L: linux-mm@xxxxxxxxx
> @@ -12328,7 +12328,7 @@ F: drivers/power/supply/huawei-gaokun-ba
> F: drivers/usb/typec/ucsi/ucsi_huawei_gaokun.c
> F: include/linux/platform_data/huawei-gaokun-ec.h
>
> -HUGETLB SUBSYSTEM
> +MEMORY MANAGEMENT - HUGETLB
> M: Muchun Song <muchun.song@xxxxxxxxx>
> M: Oscar Salvador <osalvador@xxxxxxx>
> R: David Hildenbrand <david@xxxxxxxxxx>
> @@ -12362,7 +12362,7 @@ W: https://linuxtv.org
> T: git git://linuxtv.org/media.git
> F: drivers/media/platform/st/sti/hva
>
> -HWPOISON MEMORY FAILURE HANDLING
> +MEMORY MANAGEMENT - HWPOISON MEMORY FAILURE HANDLING
> M: Miaohe Lin <linmiaohe@xxxxxxxxxx>
> R: Naoya Horiguchi <nao.horiguchi@xxxxxxxxx>
> L: linux-mm@xxxxxxxxx
> @@ -17370,7 +17370,7 @@ F: arch/*/include/asm/sync_core.h
> F: include/uapi/linux/membarrier.h
> F: kernel/sched/membarrier.c
>
> -MEMBLOCK AND MEMORY MANAGEMENT INITIALIZATION
> +MEMORY MANAGEMENT - MEMBLOCK AND INITIALIZATION
> M: Mike Rapoport <rppt@xxxxxxxxxx>
> L: linux-mm@xxxxxxxxx
> S: Maintained
> @@ -17879,7 +17879,7 @@ F: rust/kernel/mm.rs
> F: rust/kernel/mm/
> F: rust/kernel/page.rs
>
> -MEMORY MAPPING
> +MEMORY MANAGEMENT - MEMORY MAPPING
> M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> M: Liam R. Howlett <liam@xxxxxxxxxxxxx>
> M: Lorenzo Stoakes <ljs@xxxxxxxxxx>
> @@ -17916,7 +17916,7 @@ F: mm/vma_internal.h
> F: tools/testing/selftests/mm/merge.c
> F: tools/testing/vma/
>
> -MEMORY MAPPING - LOCKING
> +MEMORY MANAGEMENT - MEMORY MAPPING - LOCKING
> M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> M: Suren Baghdasaryan <surenb@xxxxxxxxxx>
> M: Liam R. Howlett <liam@xxxxxxxxxxxxx>
> @@ -17932,7 +17932,7 @@ F: include/linux/mmap_lock.h
> F: include/trace/events/mmap_lock.h
> F: mm/mmap_lock.c
>
> -MEMORY MAPPING - MADVISE (MEMORY ADVICE)
> +MEMORY MANAGEMENT - MEMORY MAPPING - MADVISE (MEMORY ADVICE)
> M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> M: Liam R. Howlett <liam@xxxxxxxxxxxxx>
> M: Lorenzo Stoakes <ljs@xxxxxxxxxx>
> @@ -18728,7 +18728,7 @@ S: Maintained
> F: drivers/phy/marvell/phy-mmp3-usb.c
> F: drivers/phy/marvell/phy-pxa-usb.c
>
> -MMU GATHER AND TLB INVALIDATION
> +MEMORY MANAGEMENT - MMU GATHER AND TLB INVALIDATION
> M: Will Deacon <will@xxxxxxxxxx>
> M: "Aneesh Kumar K.V" <aneesh.kumar@xxxxxxxxxx>
> M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> @@ -21113,7 +21113,7 @@ F: Documentation/core-api/padata.rst
> F: include/linux/padata.h
> F: kernel/padata.c
>
> -PAGE CACHE
> +MEMORY MANAGEMENT - PAGE CACHE
> M: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
> M: Jan Kara <jack@xxxxxxx>
> L: linux-fsdevel@xxxxxxxxxxxxxxx
> @@ -21142,7 +21142,7 @@ F: include/net/page_pool/
> F: include/trace/events/page_pool.h
> F: net/core/page_pool.c
>
> -PAGE TABLE CHECK
> +MEMORY MANAGEMENT - PAGE TABLE CHECK
> M: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> L: linux-mm@xxxxxxxxx
> @@ -21829,7 +21829,7 @@ S: Maintained
> F: Documentation/networking/device_drivers/ethernet/pensando/ionic.rst
> F: drivers/net/ethernet/pensando/
>
> -PER-CPU MEMORY ALLOCATOR
> +MEMORY MANAGEMENT - PER-CPU MEMORY ALLOCATOR
> M: Dennis Zhou <dennis@xxxxxxxxxx>
> M: Tejun Heo <tj@xxxxxxxxxx>
> M: Christoph Lameter <cl@xxxxxxxxxx>
> @@ -25539,7 +25539,7 @@ T: git git://linuxtv.org/media.git
> F: drivers/media/i2c/rj54n1cb0c.c
> F: include/media/i2c/rj54n1cb0c.h
>
> -SHRINKER
> +MEMORY MANAGEMENT - SHRINKER
> M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> M: Dave Chinner <david@xxxxxxxxxxxxx>
> R: Qi Zheng <qi.zheng@xxxxxxxxx>
> @@ -25775,7 +25775,7 @@ S: Maintained
> F: Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml
> F: drivers/nvmem/layouts/sl28vpd.c
>
> -SLAB ALLOCATOR
> +MEMORY MANAGEMENT - SLAB ALLOCATOR
> M: Vlastimil Babka <vbabka@xxxxxxxxxx>
> M: Harry Yoo <harry@xxxxxxxxxx>
> M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> @@ -29831,7 +29831,7 @@ F: net/vmw_vsock/
> F: tools/testing/selftests/vsock/
> F: tools/testing/vsock/
>
> -VMALLOC
> +MEMORY MANAGEMENT - VMALLOC
> M: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
> M: Uladzislau Rezki <urezki@xxxxxxxxx>
> L: linux-mm@xxxxxxxxx
> @@ -30864,7 +30864,7 @@ M: "Maciej W. Rozycki" <macro@xxxxxxxx.u
> S: Maintained
> F: drivers/tty/serial/zs.*
>
> -ZSMALLOC COMPRESSED SLAB MEMORY ALLOCATOR
> +MEMORY MANAGEMENT - ZSMALLOC COMPRESSED SLAB MEMORY ALLOCATOR
> M: Minchan Kim <minchan@xxxxxxxxxx>
> M: Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx>
> L: linux-mm@xxxxxxxxx
> @@ -30887,7 +30887,7 @@ F: lib/zstd/
> N: zstd
> K: zstd
>
> -ZSWAP COMPRESSED SWAP CACHING
> +MEMORY MANAGEMENT - ZSWAP COMPRESSED SWAP CACHING
> M: Johannes Weiner <hannes@xxxxxxxxxxx>
> M: Yosry Ahmed <yosry@xxxxxxxxxx>
> M: Nhat Pham <nphamcs@xxxxxxxxx>
> _
>

What's up with things like KASAN, KFENCE, KMEMLEAK, KMSAN?

I don't have a good question for that.


--
Cheers,

David