[RFC PATCH] MAINTAINERS: add further core files to mm core section

[RFC PATCH] MAINTAINERS: add further core files to mm core section

[Lorenzo Stoakes]

There are a number of files which don't quite belong anywhere else, so
place them in the core section. If we determine in future they belong
elsewhere we can update incrementally but it is preferable that we assign
each file to a section as best we can.

Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
REVIEWERS - let me know if these seem appropriate, I'm eyeballing
this. even if they are not quite best placed a 'best effort' is still
worthwhile so we establish a place to put all mm files, we can always
incrementally update these later.

 MAINTAINERS | 28 ++++++++++++++++++++++++----
 1 file changed, 24 insertions(+), 4 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 4523a6409186..a61d56bd7aa4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
 F:	include/linux/memory-tiers.h
 F:	include/linux/mempolicy.h
 F:	include/linux/mempool.h
-F:	include/linux/memremap.h
-F:	include/linux/mmzone.h
-F:	include/linux/mmu_notifier.h
-F:	include/linux/pagewalk.h
 F:	include/trace/events/ksm.h
 F:	mm/
 F:	tools/mm/
@@ -15764,16 +15760,40 @@ S:	Maintained
 W:	http://www.linux-mm.org
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
 F:	include/linux/memory.h
+F:	include/linux/memremap.h
 F:	include/linux/mm.h
 F:	include/linux/mm_*.h
 F:	include/linux/mmdebug.h
+F:	include/linux/mmu_notifier.h
+F:	include/linux/mmzone.h
 F:	include/linux/pagewalk.h
 F:	kernel/fork.c
 F:	mm/Kconfig
 F:	mm/debug.c
+F:	mm/debug_page_ref.c
+F:	mm/debug_vm_pgtable.c
+F:	mm/folio-compat.c
+F:	mm/highmem.c
 F:	mm/init-mm.c
+F:	mm/internal.h
+F:	mm/interval_tree.c
+F:	mm/io-mapping.c
+F:	mm/ioremap.c
+F:	mm/list_lru.c
+F:	mm/maccess.c
+F:	mm/mapping_dirty_helpers.c
 F:	mm/memory.c
+F:	mm/memremap.c
+F:	mm/mmu_notifier.c
+F:	mm/mmzone.c
+F:	mm/oom_kill.c
+F:	mm/page_idle.c
 F:	mm/pagewalk.c
+F:	mm/pgtable-generic.c
+F:	mm/process_vm_access.c
+F:	mm/ptdump.c
+F:	mm/sparse-vmemmap.c
+F:	mm/sparse.c
 F:	mm/util.c

 MEMORY MANAGEMENT - EXECMEM
--
2.49.0

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[David Hildenbrand]

On 16.06.25 22:38, Lorenzo Stoakes wrote:
> There are a number of files which don't quite belong anywhere else, so
> place them in the core section. If we determine in future they belong
> elsewhere we can update incrementally but it is preferable that we assign
> each file to a section as best we can.
> 
> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> ---
> REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> this. even if they are not quite best placed a 'best effort' is still
> worthwhile so we establish a place to put all mm files, we can always
> incrementally update these later.
> 
>   MAINTAINERS | 28 ++++++++++++++++++++++++----
>   1 file changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4523a6409186..a61d56bd7aa4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
>   F:	include/linux/memory-tiers.h
>   F:	include/linux/mempolicy.h
>   F:	include/linux/mempool.h
> -F:	include/linux/memremap.h
> -F:	include/linux/mmzone.h
> -F:	include/linux/mmu_notifier.h
> -F:	include/linux/pagewalk.h
>   F:	include/trace/events/ksm.h
>   F:	mm/
>   F:	tools/mm/

Probably better to have some section than none ... was just briefly 
wondering if "CORE" is the right section for some of that. Some of that 
might be better of in a "MM MISC" section, maybe.

> @@ -15764,16 +15760,40 @@ S:	Maintained
>   W:	http://www.linux-mm.org
>   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>   F:	include/linux/memory.h
> +F:	include/linux/memremap.h
>   F:	include/linux/mm.h
>   F:	include/linux/mm_*.h
>   F:	include/linux/mmdebug.h
> +F:	include/linux/mmu_notifier.h
> +F:	include/linux/mmzone.h
>   F:	include/linux/pagewalk.h
>   F:	kernel/fork.c
>   F:	mm/Kconfig
>   F:	mm/debug.c
> +F:	mm/debug_page_ref.c
> +F:	mm/debug_vm_pgtable.c

Wondering if there should be a MM DEBUG section. But then, no idea who 
in their right mind would be willing to maintain that ;)

> +F:	mm/folio-compat.c
> +F:	mm/highmem.c
>   F:	mm/init-mm.c
> +F:	mm/internal.h
> +F:	mm/interval_tree.c
 > +F:	mm/io-mapping.c> +F:	mm/ioremap.c
> +F:	mm/list_lru.c

Smells like reclaim/memcg.

> +F:	mm/maccess.c
 > +F:	mm/mapping_dirty_helpers.c
 >   F:	mm/memory.c> +F:	mm/memremap.c

memory hotplug related. Well, one could argue that it's just a memory 
hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be
worth a separate section ...

> +F:	mm/mmu_notifier.c
> +F:	mm/mmzone.c
 > +F:	mm/oom_kill.c

This contains quite some meat. I wonder if a OOM section would be 
appropriate (Michal, I'm looking at you :) )


-- 
Cheers,

David / dhildenb

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Shakeel Butt]

On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
> On 16.06.25 22:38, Lorenzo Stoakes wrote:
> > There are a number of files which don't quite belong anywhere else, so
> > place them in the core section. If we determine in future they belong
> > elsewhere we can update incrementally but it is preferable that we assign
> > each file to a section as best we can.
> > 
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > ---
> > REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> > this. even if they are not quite best placed a 'best effort' is still
> > worthwhile so we establish a place to put all mm files, we can always
> > incrementally update these later.
> > 
> >   MAINTAINERS | 28 ++++++++++++++++++++++++----
> >   1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 4523a6409186..a61d56bd7aa4 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
> >   F:	include/linux/memory-tiers.h
> >   F:	include/linux/mempolicy.h
> >   F:	include/linux/mempool.h
> > -F:	include/linux/memremap.h
> > -F:	include/linux/mmzone.h
> > -F:	include/linux/mmu_notifier.h
> > -F:	include/linux/pagewalk.h
> >   F:	include/trace/events/ksm.h
> >   F:	mm/
> >   F:	tools/mm/
> 
> Probably better to have some section than none ... was just briefly
> wondering if "CORE" is the right section for some of that. Some of that
> might be better of in a "MM MISC" section, maybe.
> 
> > @@ -15764,16 +15760,40 @@ S:	Maintained
> >   W:	http://www.linux-mm.org
> >   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> >   F:	include/linux/memory.h
> > +F:	include/linux/memremap.h
> >   F:	include/linux/mm.h
> >   F:	include/linux/mm_*.h
> >   F:	include/linux/mmdebug.h
> > +F:	include/linux/mmu_notifier.h
> > +F:	include/linux/mmzone.h
> >   F:	include/linux/pagewalk.h
> >   F:	kernel/fork.c
> >   F:	mm/Kconfig
> >   F:	mm/debug.c
> > +F:	mm/debug_page_ref.c
> > +F:	mm/debug_vm_pgtable.c
> 
> Wondering if there should be a MM DEBUG section. But then, no idea who in
> their right mind would be willing to maintain that ;)
> 
> > +F:	mm/folio-compat.c
> > +F:	mm/highmem.c
> >   F:	mm/init-mm.c
> > +F:	mm/internal.h
> > +F:	mm/interval_tree.c
> > +F:	mm/io-mapping.c> +F:	mm/ioremap.c
> > +F:	mm/list_lru.c
> 
> Smells like reclaim/memcg.

Shrinker might be more appropriate (along with the list_lru.h)

> 
> > +F:	mm/maccess.c
> > +F:	mm/mapping_dirty_helpers.c
> >   F:	mm/memory.c> +F:	mm/memremap.c
> 
> memory hotplug related. Well, one could argue that it's just a memory
> hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be
> worth a separate section ...
> 
> > +F:	mm/mmu_notifier.c
> > +F:	mm/mmzone.c
> > +F:	mm/oom_kill.c
> 
> This contains quite some meat. I wonder if a OOM section would be
> appropriate (Michal, I'm looking at you :) )
> 

I think Michal already has a patch on OOM section which I expect he will
send out soon.

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Mike Rapoport]

On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
> On 16.06.25 22:38, Lorenzo Stoakes wrote:
> > There are a number of files which don't quite belong anywhere else, so
> > place them in the core section. If we determine in future they belong
> > elsewhere we can update incrementally but it is preferable that we assign
> > each file to a section as best we can.
> > 
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > ---
> > REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> > this. even if they are not quite best placed a 'best effort' is still
> > worthwhile so we establish a place to put all mm files, we can always
> > incrementally update these later.
> > 
> >   MAINTAINERS | 28 ++++++++++++++++++++++++----
> >   1 file changed, 24 insertions(+), 4 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 4523a6409186..a61d56bd7aa4 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
> >   F:	include/linux/memory-tiers.h
> >   F:	include/linux/mempolicy.h
> >   F:	include/linux/mempool.h
> > -F:	include/linux/memremap.h
> > -F:	include/linux/mmzone.h
> > -F:	include/linux/mmu_notifier.h
> > -F:	include/linux/pagewalk.h
> >   F:	include/trace/events/ksm.h
> >   F:	mm/
> >   F:	tools/mm/
> 
> Probably better to have some section than none ... was just briefly
> wondering if "CORE" is the right section for some of that. Some of that
> might be better of in a "MM MISC" section, maybe.

Maybe rather than add files to MM CORE we should move mm/ there and add the
MM MISC section for files we explicitly want to exclude from MM CORE?
 
> > @@ -15764,16 +15760,40 @@ S:	Maintained
> >   W:	http://www.linux-mm.org
> >   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> >   F:	include/linux/memory.h
> > +F:	include/linux/memremap.h
> >   F:	include/linux/mm.h
> >   F:	include/linux/mm_*.h
> >   F:	include/linux/mmdebug.h
> > +F:	include/linux/mmu_notifier.h
> > +F:	include/linux/mmzone.h
> >   F:	include/linux/pagewalk.h
> >   F:	kernel/fork.c
> >   F:	mm/Kconfig
> >   F:	mm/debug.c
> > +F:	mm/debug_page_ref.c
> > +F:	mm/debug_vm_pgtable.c
> 
> Wondering if there should be a MM DEBUG section. But then, no idea who in
> their right mind would be willing to maintain that ;)

The same people that maintain MM CORE? ;-)
 
> > +F:	mm/folio-compat.c
> > +F:	mm/highmem.c
> >   F:	mm/init-mm.c
> > +F:	mm/internal.h
> > +F:	mm/interval_tree.c

Looks like VMA to me.

> > +F:	mm/io-mapping.c

This is an interesting one. There are no in tree users of the only function
it contains.

> > +F:	mm/ioremap.c
> > +F:	mm/list_lru.c
> 
> Smells like reclaim/memcg.
> 
> > +F:	mm/maccess.c
> > +F:	mm/mapping_dirty_helpers.c
> >  F:	mm/memory.c
> > +F:	mm/memremap.c
> 
> memory hotplug related. Well, one could argue that it's just a memory
> hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be
> worth a separate section ...
> 
> > +F:	mm/mmu_notifier.c
> > +F:	mm/mmzone.c
> > +F:	mm/oom_kill.c
> 
> This contains quite some meat. I wonder if a OOM section would be
> appropriate (Michal, I'm looking at you :) )
>
> -- 
> Cheers,
> 
> David / dhildenb

-- 
Sincerely yours,
Mike.

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[David Hildenbrand]

On 17.06.25 05:53, Mike Rapoport wrote:
> On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
>> On 16.06.25 22:38, Lorenzo Stoakes wrote:
>>> There are a number of files which don't quite belong anywhere else, so
>>> place them in the core section. If we determine in future they belong
>>> elsewhere we can update incrementally but it is preferable that we assign
>>> each file to a section as best we can.
>>>
>>> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>>> ---
>>> REVIEWERS - let me know if these seem appropriate, I'm eyeballing
>>> this. even if they are not quite best placed a 'best effort' is still
>>> worthwhile so we establish a place to put all mm files, we can always
>>> incrementally update these later.
>>>
>>>    MAINTAINERS | 28 ++++++++++++++++++++++++----
>>>    1 file changed, 24 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 4523a6409186..a61d56bd7aa4 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
>>>    F:	include/linux/memory-tiers.h
>>>    F:	include/linux/mempolicy.h
>>>    F:	include/linux/mempool.h
>>> -F:	include/linux/memremap.h
>>> -F:	include/linux/mmzone.h
>>> -F:	include/linux/mmu_notifier.h
>>> -F:	include/linux/pagewalk.h
>>>    F:	include/trace/events/ksm.h
>>>    F:	mm/
>>>    F:	tools/mm/
>>
>> Probably better to have some section than none ... was just briefly
>> wondering if "CORE" is the right section for some of that. Some of that
>> might be better of in a "MM MISC" section, maybe.
> 
> Maybe rather than add files to MM CORE we should move mm/ there and add the
> MM MISC section for files we explicitly want to exclude from MM CORE?

Also an option, yes,

>   
>>> @@ -15764,16 +15760,40 @@ S:	Maintained
>>>    W:	http://www.linux-mm.org
>>>    T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>>>    F:	include/linux/memory.h
>>> +F:	include/linux/memremap.h
>>>    F:	include/linux/mm.h
>>>    F:	include/linux/mm_*.h
>>>    F:	include/linux/mmdebug.h
>>> +F:	include/linux/mmu_notifier.h
>>> +F:	include/linux/mmzone.h
>>>    F:	include/linux/pagewalk.h
>>>    F:	kernel/fork.c
>>>    F:	mm/Kconfig
>>>    F:	mm/debug.c
>>> +F:	mm/debug_page_ref.c
>>> +F:	mm/debug_vm_pgtable.c
>>
>> Wondering if there should be a MM DEBUG section. But then, no idea who in
>> their right mind would be willing to maintain that ;)
> 
> The same people that maintain MM CORE? ;-)

Heh :P

>   
>>> +F:	mm/folio-compat.c
>>> +F:	mm/highmem.c
>>>    F:	mm/init-mm.c
>>> +F:	mm/internal.h
>>> +F:	mm/interval_tree.c
> 
> Looks like VMA to me.

It's more about anon_vma I guess, so rmap ... maybe.

-- 
Cheers,

David / dhildenb

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Lorenzo Stoakes]

On Tue, Jun 17, 2025 at 09:59:01AM +0200, David Hildenbrand wrote:
> On 17.06.25 05:53, Mike Rapoport wrote:
> > On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
> > > On 16.06.25 22:38, Lorenzo Stoakes wrote:
> > > > There are a number of files which don't quite belong anywhere else, so
> > > > place them in the core section. If we determine in future they belong
> > > > elsewhere we can update incrementally but it is preferable that we assign
> > > > each file to a section as best we can.
> > > >
> > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > > ---
> > > > REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> > > > this. even if they are not quite best placed a 'best effort' is still
> > > > worthwhile so we establish a place to put all mm files, we can always
> > > > incrementally update these later.
> > > >
> > > >    MAINTAINERS | 28 ++++++++++++++++++++++++----
> > > >    1 file changed, 24 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 4523a6409186..a61d56bd7aa4 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
> > > >    F:	include/linux/memory-tiers.h
> > > >    F:	include/linux/mempolicy.h
> > > >    F:	include/linux/mempool.h
> > > > -F:	include/linux/memremap.h
> > > > -F:	include/linux/mmzone.h
> > > > -F:	include/linux/mmu_notifier.h
> > > > -F:	include/linux/pagewalk.h
> > > >    F:	include/trace/events/ksm.h
> > > >    F:	mm/
> > > >    F:	tools/mm/
> > >
> > > Probably better to have some section than none ... was just briefly
> > > wondering if "CORE" is the right section for some of that. Some of that
> > > might be better of in a "MM MISC" section, maybe.
> >
> > Maybe rather than add files to MM CORE we should move mm/ there and add the
> > MM MISC section for files we explicitly want to exclude from MM CORE?
>
> Also an option, yes,

These suggestions seem to be roughly the same no? :)

Maybe the MM section itself should just contain mm/ and we move everything else
+ stragglers to misc?

Now who, whose's first name begins with 'D' and surname begins with 'H' should
we put as M there... :P well...

>
> > > > @@ -15764,16 +15760,40 @@ S:	Maintained
> > > >    W:	http://www.linux-mm.org
> > > >    T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > > >    F:	include/linux/memory.h
> > > > +F:	include/linux/memremap.h
> > > >    F:	include/linux/mm.h
> > > >    F:	include/linux/mm_*.h
> > > >    F:	include/linux/mmdebug.h
> > > > +F:	include/linux/mmu_notifier.h
> > > > +F:	include/linux/mmzone.h
> > > >    F:	include/linux/pagewalk.h
> > > >    F:	kernel/fork.c
> > > >    F:	mm/Kconfig
> > > >    F:	mm/debug.c
> > > > +F:	mm/debug_page_ref.c
> > > > +F:	mm/debug_vm_pgtable.c
> > >
> > > Wondering if there should be a MM DEBUG section. But then, no idea who in
> > > their right mind would be willing to maintain that ;)
> >
> > The same people that maintain MM CORE? ;-)
>
> Heh :P

...hmm yes easier to just copy/paste these good idea ;)

>
> > > > +F:	mm/folio-compat.c
> > > > +F:	mm/highmem.c
> > > >    F:	mm/init-mm.c
> > > > +F:	mm/internal.h
> > > > +F:	mm/interval_tree.c
> >
> > Looks like VMA to me.
>
> It's more about anon_vma I guess, so rmap ... maybe.

Ack.

>
> --
> Cheers,
>
> David / dhildenb
>

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Lorenzo Stoakes]

On Mon, Jun 16, 2025 at 03:56:02PM -0700, Shakeel Butt wrote:
> On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
> > On 16.06.25 22:38, Lorenzo Stoakes wrote:
> > > There are a number of files which don't quite belong anywhere else, so
> > > place them in the core section. If we determine in future they belong
> > > elsewhere we can update incrementally but it is preferable that we assign
> > > each file to a section as best we can.
> > >
> > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > ---
> > > REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> > > this. even if they are not quite best placed a 'best effort' is still
> > > worthwhile so we establish a place to put all mm files, we can always
> > > incrementally update these later.
> > >
> > >   MAINTAINERS | 28 ++++++++++++++++++++++++----
> > >   1 file changed, 24 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 4523a6409186..a61d56bd7aa4 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
> > >   F:	include/linux/memory-tiers.h
> > >   F:	include/linux/mempolicy.h
> > >   F:	include/linux/mempool.h
> > > -F:	include/linux/memremap.h
> > > -F:	include/linux/mmzone.h
> > > -F:	include/linux/mmu_notifier.h
> > > -F:	include/linux/pagewalk.h
> > >   F:	include/trace/events/ksm.h
> > >   F:	mm/
> > >   F:	tools/mm/
> >
> > Probably better to have some section than none ... was just briefly
> > wondering if "CORE" is the right section for some of that. Some of that
> > might be better of in a "MM MISC" section, maybe.
> >
> > > @@ -15764,16 +15760,40 @@ S:	Maintained
> > >   W:	http://www.linux-mm.org
> > >   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > >   F:	include/linux/memory.h
> > > +F:	include/linux/memremap.h
> > >   F:	include/linux/mm.h
> > >   F:	include/linux/mm_*.h
> > >   F:	include/linux/mmdebug.h
> > > +F:	include/linux/mmu_notifier.h
> > > +F:	include/linux/mmzone.h
> > >   F:	include/linux/pagewalk.h
> > >   F:	kernel/fork.c
> > >   F:	mm/Kconfig
> > >   F:	mm/debug.c
> > > +F:	mm/debug_page_ref.c
> > > +F:	mm/debug_vm_pgtable.c
> >
> > Wondering if there should be a MM DEBUG section. But then, no idea who in
> > their right mind would be willing to maintain that ;)
> >
> > > +F:	mm/folio-compat.c
> > > +F:	mm/highmem.c
> > >   F:	mm/init-mm.c
> > > +F:	mm/internal.h
> > > +F:	mm/interval_tree.c
> > > +F:	mm/io-mapping.c> +F:	mm/ioremap.c
> > > +F:	mm/list_lru.c
> >
> > Smells like reclaim/memcg.
>
> Shrinker might be more appropriate (along with the list_lru.h)

Yeah I struggled with this one. It's a weird one, it's like a generic LRU
algorithm:

zswap_lru_add()
binder_lru_freelist_add()
-> list_lru_add()

Also called internally by list_lru_add_obj() which is used for dentry LRUs by a
number of filesystems

But also by the working set code in workingset_update_node() :)

So it's a bit all over the place.

I wonder whether best for mm misc as a result?

>
> >
> > > +F:	mm/maccess.c
> > > +F:	mm/mapping_dirty_helpers.c
> > >   F:	mm/memory.c> +F:	mm/memremap.c
> >
> > memory hotplug related. Well, one could argue that it's just a memory
> > hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be
> > worth a separate section ...
> >
> > > +F:	mm/mmu_notifier.c
> > > +F:	mm/mmzone.c
> > > +F:	mm/oom_kill.c
> >
> > This contains quite some meat. I wonder if a OOM section would be
> > appropriate (Michal, I'm looking at you :) )
> >
>
> I think Michal already has a patch on OOM section which I expect he will
> send out soon.
>

Yes saw that and acked that thanks :)

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Lorenzo Stoakes]

On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
> On 16.06.25 22:38, Lorenzo Stoakes wrote:
> > There are a number of files which don't quite belong anywhere else, so
> > place them in the core section. If we determine in future they belong
> > elsewhere we can update incrementally but it is preferable that we assign
> > each file to a section as best we can.
> >
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > ---
> > REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> > this. even if they are not quite best placed a 'best effort' is still
> > worthwhile so we establish a place to put all mm files, we can always
> > incrementally update these later.
> >
> >   MAINTAINERS | 28 ++++++++++++++++++++++++----
> >   1 file changed, 24 insertions(+), 4 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 4523a6409186..a61d56bd7aa4 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
> >   F:	include/linux/memory-tiers.h
> >   F:	include/linux/mempolicy.h
> >   F:	include/linux/mempool.h
> > -F:	include/linux/memremap.h
> > -F:	include/linux/mmzone.h
> > -F:	include/linux/mmu_notifier.h
> > -F:	include/linux/pagewalk.h
> >   F:	include/trace/events/ksm.h
> >   F:	mm/
> >   F:	tools/mm/
>
> Probably better to have some section than none ... was just briefly
> wondering if "CORE" is the right section for some of that. Some of that
> might be better of in a "MM MISC" section, maybe.

Responded in thread elsewhere on this but yes defo!

>
> > @@ -15764,16 +15760,40 @@ S:	Maintained
> >   W:	http://www.linux-mm.org
> >   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> >   F:	include/linux/memory.h
> > +F:	include/linux/memremap.h
> >   F:	include/linux/mm.h
> >   F:	include/linux/mm_*.h
> >   F:	include/linux/mmdebug.h
> > +F:	include/linux/mmu_notifier.h
> > +F:	include/linux/mmzone.h
> >   F:	include/linux/pagewalk.h
> >   F:	kernel/fork.c
> >   F:	mm/Kconfig
> >   F:	mm/debug.c
> > +F:	mm/debug_page_ref.c
> > +F:	mm/debug_vm_pgtable.c
>
> Wondering if there should be a MM DEBUG section. But then, no idea who in
> their right mind would be willing to maintain that ;)

Thanks for volunteering! :P

Yeah I did think about this. But given the above it's maybe better to put in mm
misc until we a brave soul steps up? :)

I have a few other new sections that are possibly ones we should add:

CMA
DMA pool
statistics (e.g. vmpressure.c, vmstat.c)

But these could go to misc for the time being also.

Of these 3 possibly statistics is the one that makes the best case I think.

>
> > +F:	mm/folio-compat.c
> > +F:	mm/highmem.c
> >   F:	mm/init-mm.c
> > +F:	mm/internal.h
> > +F:	mm/interval_tree.c
> > +F:	mm/io-mapping.c> +F:	mm/ioremap.c
> > +F:	mm/list_lru.c
>
> Smells like reclaim/memcg.
>
> > +F:	mm/maccess.c
> > +F:	mm/mapping_dirty_helpers.c
> >   F:	mm/memory.c
>+F:	mm/memremap.c
>
> memory hotplug related. Well, one could argue that it's just a memory
> hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be
> worth a separate section ...

Hm not sure? Again maybe best for misc for now until we decide :)

>
> > +F:	mm/mmu_notifier.c
> > +F:	mm/mmzone.c
> > +F:	mm/oom_kill.c
>
> This contains quite some meat. I wonder if a OOM section would be
> appropriate (Michal, I'm looking at you :) )

As Shakeel points out that's already done (see [0]).

[0]: https://lore.kernel.org/linux-mm/20250617085819.355838-1-mhocko@kernel.org/

>
>
> --
> Cheers,
>
> David / dhildenb
>

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[David Hildenbrand]

On 17.06.25 17:04, Lorenzo Stoakes wrote:
> On Tue, Jun 17, 2025 at 09:59:01AM +0200, David Hildenbrand wrote:
>> On 17.06.25 05:53, Mike Rapoport wrote:
>>> On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
>>>> On 16.06.25 22:38, Lorenzo Stoakes wrote:
>>>>> There are a number of files which don't quite belong anywhere else, so
>>>>> place them in the core section. If we determine in future they belong
>>>>> elsewhere we can update incrementally but it is preferable that we assign
>>>>> each file to a section as best we can.
>>>>>
>>>>> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>>>>> ---
>>>>> REVIEWERS - let me know if these seem appropriate, I'm eyeballing
>>>>> this. even if they are not quite best placed a 'best effort' is still
>>>>> worthwhile so we establish a place to put all mm files, we can always
>>>>> incrementally update these later.
>>>>>
>>>>>     MAINTAINERS | 28 ++++++++++++++++++++++++----
>>>>>     1 file changed, 24 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>>> index 4523a6409186..a61d56bd7aa4 100644
>>>>> --- a/MAINTAINERS
>>>>> +++ b/MAINTAINERS
>>>>> @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
>>>>>     F:	include/linux/memory-tiers.h
>>>>>     F:	include/linux/mempolicy.h
>>>>>     F:	include/linux/mempool.h
>>>>> -F:	include/linux/memremap.h
>>>>> -F:	include/linux/mmzone.h
>>>>> -F:	include/linux/mmu_notifier.h
>>>>> -F:	include/linux/pagewalk.h
>>>>>     F:	include/trace/events/ksm.h
>>>>>     F:	mm/
>>>>>     F:	tools/mm/
>>>>
>>>> Probably better to have some section than none ... was just briefly
>>>> wondering if "CORE" is the right section for some of that. Some of that
>>>> might be better of in a "MM MISC" section, maybe.
>>>
>>> Maybe rather than add files to MM CORE we should move mm/ there and add the
>>> MM MISC section for files we explicitly want to exclude from MM CORE?
>>
>> Also an option, yes,
> 
> These suggestions seem to be roughly the same no? :)
> 
> Maybe the MM section itself should just contain mm/ and we move everything else
> + stragglers to misc?
> 
> Now who, whose's first name begins with 'D' and surname begins with 'H' should
> we put as M there... :P well...

Most of these files are fairly small with little activity, so I don't 
particularly care.

Happy once the real big things in there (e.g., OOM) have a dedicate section.

-- 
Cheers,

David / dhildenb

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Shakeel Butt]

On Tue, Jun 17, 2025 at 04:22:33PM +0100, Lorenzo Stoakes wrote:
> On Mon, Jun 16, 2025 at 03:56:02PM -0700, Shakeel Butt wrote:
> > On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
> > > On 16.06.25 22:38, Lorenzo Stoakes wrote:
> > > > There are a number of files which don't quite belong anywhere else, so
> > > > place them in the core section. If we determine in future they belong
> > > > elsewhere we can update incrementally but it is preferable that we assign
> > > > each file to a section as best we can.
> > > >
> > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > > ---
> > > > REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> > > > this. even if they are not quite best placed a 'best effort' is still
> > > > worthwhile so we establish a place to put all mm files, we can always
> > > > incrementally update these later.
> > > >
> > > >   MAINTAINERS | 28 ++++++++++++++++++++++++----
> > > >   1 file changed, 24 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > index 4523a6409186..a61d56bd7aa4 100644
> > > > --- a/MAINTAINERS
> > > > +++ b/MAINTAINERS
> > > > @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
> > > >   F:	include/linux/memory-tiers.h
> > > >   F:	include/linux/mempolicy.h
> > > >   F:	include/linux/mempool.h
> > > > -F:	include/linux/memremap.h
> > > > -F:	include/linux/mmzone.h
> > > > -F:	include/linux/mmu_notifier.h
> > > > -F:	include/linux/pagewalk.h
> > > >   F:	include/trace/events/ksm.h
> > > >   F:	mm/
> > > >   F:	tools/mm/
> > >
> > > Probably better to have some section than none ... was just briefly
> > > wondering if "CORE" is the right section for some of that. Some of that
> > > might be better of in a "MM MISC" section, maybe.
> > >
> > > > @@ -15764,16 +15760,40 @@ S:	Maintained
> > > >   W:	http://www.linux-mm.org
> > > >   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > > >   F:	include/linux/memory.h
> > > > +F:	include/linux/memremap.h
> > > >   F:	include/linux/mm.h
> > > >   F:	include/linux/mm_*.h
> > > >   F:	include/linux/mmdebug.h
> > > > +F:	include/linux/mmu_notifier.h
> > > > +F:	include/linux/mmzone.h
> > > >   F:	include/linux/pagewalk.h
> > > >   F:	kernel/fork.c
> > > >   F:	mm/Kconfig
> > > >   F:	mm/debug.c
> > > > +F:	mm/debug_page_ref.c
> > > > +F:	mm/debug_vm_pgtable.c
> > >
> > > Wondering if there should be a MM DEBUG section. But then, no idea who in
> > > their right mind would be willing to maintain that ;)
> > >
> > > > +F:	mm/folio-compat.c
> > > > +F:	mm/highmem.c
> > > >   F:	mm/init-mm.c
> > > > +F:	mm/internal.h
> > > > +F:	mm/interval_tree.c
> > > > +F:	mm/io-mapping.c> +F:	mm/ioremap.c
> > > > +F:	mm/list_lru.c
> > >
> > > Smells like reclaim/memcg.
> >
> > Shrinker might be more appropriate (along with the list_lru.h)
> 
> Yeah I struggled with this one. It's a weird one, it's like a generic LRU
> algorithm:
> 
> zswap_lru_add()
> binder_lru_freelist_add()
> -> list_lru_add()
> 
> Also called internally by list_lru_add_obj() which is used for dentry LRUs by a
> number of filesystems
> 
> But also by the working set code in workingset_update_node() :)
> 
> So it's a bit all over the place.
> 
> I wonder whether best for mm misc as a result?

list_lru is the data structure / abstraction to interact with the
shrinker. Kernel components which can consume large amount of kernel
memory and has a way to drop some on memory pressure (e.g. some form of
cache) register themselves with the shrinker and list_lru is used to
store/link their internal objects which the shrinker can drop/reclaim
during memory reclaim.

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Lorenzo Stoakes]

On Tue, Jun 17, 2025 at 10:51:50AM -0700, Shakeel Butt wrote:
> On Tue, Jun 17, 2025 at 04:22:33PM +0100, Lorenzo Stoakes wrote:
> > On Mon, Jun 16, 2025 at 03:56:02PM -0700, Shakeel Butt wrote:
> > > On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
> > > > On 16.06.25 22:38, Lorenzo Stoakes wrote:
> > > > > There are a number of files which don't quite belong anywhere else, so
> > > > > place them in the core section. If we determine in future they belong
> > > > > elsewhere we can update incrementally but it is preferable that we assign
> > > > > each file to a section as best we can.
> > > > >
> > > > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > > > ---
> > > > > REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> > > > > this. even if they are not quite best placed a 'best effort' is still
> > > > > worthwhile so we establish a place to put all mm files, we can always
> > > > > incrementally update these later.
> > > > >
> > > > >   MAINTAINERS | 28 ++++++++++++++++++++++++----
> > > > >   1 file changed, 24 insertions(+), 4 deletions(-)
> > > > >
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > > > index 4523a6409186..a61d56bd7aa4 100644
> > > > > --- a/MAINTAINERS
> > > > > +++ b/MAINTAINERS
> > > > > @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
> > > > >   F:	include/linux/memory-tiers.h
> > > > >   F:	include/linux/mempolicy.h
> > > > >   F:	include/linux/mempool.h
> > > > > -F:	include/linux/memremap.h
> > > > > -F:	include/linux/mmzone.h
> > > > > -F:	include/linux/mmu_notifier.h
> > > > > -F:	include/linux/pagewalk.h
> > > > >   F:	include/trace/events/ksm.h
> > > > >   F:	mm/
> > > > >   F:	tools/mm/
> > > >
> > > > Probably better to have some section than none ... was just briefly
> > > > wondering if "CORE" is the right section for some of that. Some of that
> > > > might be better of in a "MM MISC" section, maybe.
> > > >
> > > > > @@ -15764,16 +15760,40 @@ S:	Maintained
> > > > >   W:	http://www.linux-mm.org
> > > > >   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > > > >   F:	include/linux/memory.h
> > > > > +F:	include/linux/memremap.h
> > > > >   F:	include/linux/mm.h
> > > > >   F:	include/linux/mm_*.h
> > > > >   F:	include/linux/mmdebug.h
> > > > > +F:	include/linux/mmu_notifier.h
> > > > > +F:	include/linux/mmzone.h
> > > > >   F:	include/linux/pagewalk.h
> > > > >   F:	kernel/fork.c
> > > > >   F:	mm/Kconfig
> > > > >   F:	mm/debug.c
> > > > > +F:	mm/debug_page_ref.c
> > > > > +F:	mm/debug_vm_pgtable.c
> > > >
> > > > Wondering if there should be a MM DEBUG section. But then, no idea who in
> > > > their right mind would be willing to maintain that ;)
> > > >
> > > > > +F:	mm/folio-compat.c
> > > > > +F:	mm/highmem.c
> > > > >   F:	mm/init-mm.c
> > > > > +F:	mm/internal.h
> > > > > +F:	mm/interval_tree.c
> > > > > +F:	mm/io-mapping.c> +F:	mm/ioremap.c
> > > > > +F:	mm/list_lru.c
> > > >
> > > > Smells like reclaim/memcg.
> > >
> > > Shrinker might be more appropriate (along with the list_lru.h)
> >
> > Yeah I struggled with this one. It's a weird one, it's like a generic LRU
> > algorithm:
> >
> > zswap_lru_add()
> > binder_lru_freelist_add()
> > -> list_lru_add()
> >
> > Also called internally by list_lru_add_obj() which is used for dentry LRUs by a
> > number of filesystems
> >
> > But also by the working set code in workingset_update_node() :)
> >
> > So it's a bit all over the place.
> >
> > I wonder whether best for mm misc as a result?
>
> list_lru is the data structure / abstraction to interact with the
> shrinker. Kernel components which can consume large amount of kernel
> memory and has a way to drop some on memory pressure (e.g. some form of
> cache) register themselves with the shrinker and list_lru is used to
> store/link their internal objects which the shrinker can drop/reclaim
> during memory reclaim.

Ahhh you're right! Sorry, not very familiar with this code so going off a
fuzzy match as to what uses these functions etc.

So it seems then that include/linux/list_lru.h and mm/list_lru.c belong in
the shrinker section, ack will move over there when I tackle the rest of
this!

Cheers! :)

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Vlastimil Babka]

On 6/16/25 23:10, David Hildenbrand wrote:
> On 16.06.25 22:38, Lorenzo Stoakes wrote:
>> There are a number of files which don't quite belong anywhere else, so
>> place them in the core section. If we determine in future they belong
>> elsewhere we can update incrementally but it is preferable that we assign
>> each file to a section as best we can.
>> 
>> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
>> ---
>> REVIEWERS - let me know if these seem appropriate, I'm eyeballing
>> this. even if they are not quite best placed a 'best effort' is still
>> worthwhile so we establish a place to put all mm files, we can always
>> incrementally update these later.

>> @@ -15764,16 +15760,40 @@ S:	Maintained
>>   W:	http://www.linux-mm.org
>>   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
>>   F:	include/linux/memory.h
>> +F:	include/linux/memremap.h
>>   F:	include/linux/mm.h
>>   F:	include/linux/mm_*.h
>>   F:	include/linux/mmdebug.h
>> +F:	include/linux/mmu_notifier.h
>> +F:	include/linux/mmzone.h
>>   F:	include/linux/pagewalk.h
>>   F:	kernel/fork.c
>>   F:	mm/Kconfig
>>   F:	mm/debug.c
>> +F:	mm/debug_page_ref.c
>> +F:	mm/debug_vm_pgtable.c
> 
> Wondering if there should be a MM DEBUG section. But then, no idea who 
> in their right mind would be willing to maintain that ;)

Guess I'm not in my right mind, but I'd be fine with that. Although most of
my experience is with page_owner and debug_pagealloc which are tied to the
page allocator. And I think it's better when these debug files are in the
section of the functionality they debug. mm/debug_page_ref.c could probably
go to the page allocator. mm/debug_vm_pgtable.c is maybe related to
pagewalk? (it could be redone to a kunit test, btw?). Only mm/debug.c seems
a mix of stuff related to various mm parts... maybe could stay in core then.

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Alistair Popple]

On Tue, Jun 17, 2025 at 04:26:42PM +0100, Lorenzo Stoakes wrote:
> On Mon, Jun 16, 2025 at 11:10:41PM +0200, David Hildenbrand wrote:
> > On 16.06.25 22:38, Lorenzo Stoakes wrote:
> > > There are a number of files which don't quite belong anywhere else, so
> > > place them in the core section. If we determine in future they belong
> > > elsewhere we can update incrementally but it is preferable that we assign
> > > each file to a section as best we can.
> > >
> > > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> > > ---
> > > REVIEWERS - let me know if these seem appropriate, I'm eyeballing
> > > this. even if they are not quite best placed a 'best effort' is still
> > > worthwhile so we establish a place to put all mm files, we can always
> > > incrementally update these later.
> > >
> > >   MAINTAINERS | 28 ++++++++++++++++++++++++----
> > >   1 file changed, 24 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index 4523a6409186..a61d56bd7aa4 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -15740,10 +15740,6 @@ F:	include/linux/memory_hotplug.h
> > >   F:	include/linux/memory-tiers.h
> > >   F:	include/linux/mempolicy.h
> > >   F:	include/linux/mempool.h
> > > -F:	include/linux/memremap.h
> > > -F:	include/linux/mmzone.h
> > > -F:	include/linux/mmu_notifier.h
> > > -F:	include/linux/pagewalk.h
> > >   F:	include/trace/events/ksm.h
> > >   F:	mm/
> > >   F:	tools/mm/
> >
> > Probably better to have some section than none ... was just briefly
> > wondering if "CORE" is the right section for some of that. Some of that
> > might be better of in a "MM MISC" section, maybe.
> 
> Responded in thread elsewhere on this but yes defo!
> 
> >
> > > @@ -15764,16 +15760,40 @@ S:	Maintained
> > >   W:	http://www.linux-mm.org
> > >   T:	git git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
> > >   F:	include/linux/memory.h
> > > +F:	include/linux/memremap.h
> > >   F:	include/linux/mm.h
> > >   F:	include/linux/mm_*.h
> > >   F:	include/linux/mmdebug.h
> > > +F:	include/linux/mmu_notifier.h
> > > +F:	include/linux/mmzone.h
> > >   F:	include/linux/pagewalk.h
> > >   F:	kernel/fork.c
> > >   F:	mm/Kconfig
> > >   F:	mm/debug.c
> > > +F:	mm/debug_page_ref.c
> > > +F:	mm/debug_vm_pgtable.c
> >
> > Wondering if there should be a MM DEBUG section. But then, no idea who in
> > their right mind would be willing to maintain that ;)
> 
> Thanks for volunteering! :P
> 
> Yeah I did think about this. But given the above it's maybe better to put in mm
> misc until we a brave soul steps up? :)
> 
> I have a few other new sections that are possibly ones we should add:
> 
> CMA
> DMA pool
> statistics (e.g. vmpressure.c, vmstat.c)
> 
> But these could go to misc for the time being also.
> 
> Of these 3 possibly statistics is the one that makes the best case I think.
> 
> >
> > > +F:	mm/folio-compat.c
> > > +F:	mm/highmem.c
> > >   F:	mm/init-mm.c
> > > +F:	mm/internal.h
> > > +F:	mm/interval_tree.c
> > > +F:	mm/io-mapping.c> +F:	mm/ioremap.c
> > > +F:	mm/list_lru.c
> >
> > Smells like reclaim/memcg.
> >
> > > +F:	mm/maccess.c
> > > +F:	mm/mapping_dirty_helpers.c
> > >   F:	mm/memory.c
> >+F:	mm/memremap.c
> >
> > memory hotplug related. Well, one could argue that it's just a memory
> > hotplug user. It's mostly ZONE_DEVICE handling. Wonder if that would be
> > worth a separate section ...
> 
> Hm not sure? Again maybe best for misc for now until we decide :)

It seems relatively small, but if we decide it needs it's own section feel free
to put my name down.

> >
> > > +F:	mm/mmu_notifier.c
> > > +F:	mm/mmzone.c
> > > +F:	mm/oom_kill.c
> >
> > This contains quite some meat. I wonder if a OOM section would be
> > appropriate (Michal, I'm looking at you :) )
> 
> As Shakeel points out that's already done (see [0]).
> 
> [0]: https://lore.kernel.org/linux-mm/20250617085819.355838-1-mhocko@kernel.org/
> 
> >
> >
> > --
> > Cheers,
> >
> > David / dhildenb
> >
> 

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Lorenzo Stoakes]

On Tue, Jun 17, 2025 at 06:53:53AM +0300, Mike Rapoport wrote:
>
> > > +F:	mm/io-mapping.c
>
> This is an interesting one. There are no in tree users of the only function
> it contains.

Hi Christoph,

Was going through and making sure mm files have places in MAINTAINERS and
came across this - I see you added this, but it doesn't appear to be being
used anywhere. Should it be removed or if not wonder where it ought to go?

We're contemplating an 'MM MISC' section where it could live potentially.

Cheers, Lorenzo

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Vlastimil Babka]

On 7/22/25 15:53, Lorenzo Stoakes wrote:
> On Tue, Jun 17, 2025 at 06:53:53AM +0300, Mike Rapoport wrote:
>>
>> > > +F:	mm/io-mapping.c
>>
>> This is an interesting one. There are no in tree users of the only function
>> it contains.
> 
> Hi Christoph,
> 
> Was going through and making sure mm files have places in MAINTAINERS and
> came across this - I see you added this, but it doesn't appear to be being
> used anywhere. Should it be removed or if not wonder where it ought to go?

It seems it only gained its only user in b739f125e4eb ("i915: use
io_mapping_map_user") but reverted a month later by 0e4fe0c9f2f9 ("Revert
"i915: use io_mapping_map_user"") all that in 2021.

Ideally i915 would be converted again with the revert reasons investigated
properly this time. Otherwise we should remove the thing.

> We're contemplating an 'MM MISC' section where it could live potentially.
> 
> Cheers, Lorenzo

Re: [RFC PATCH] MAINTAINERS: add further core files to mm core section

[Christoph Hellwig]

On Tue, Jul 22, 2025 at 04:22:59PM +0200, Vlastimil Babka wrote:
> It seems it only gained its only user in b739f125e4eb ("i915: use
> io_mapping_map_user") but reverted a month later by 0e4fe0c9f2f9 ("Revert
> "i915: use io_mapping_map_user"") all that in 2021.
> 
> Ideally i915 would be converted again with the revert reasons investigated
> properly this time. Otherwise we should remove the thing.

Yeah, someone needs to sort the i915 mess, and it's sad they just
reverted things instead of trying to understand it.

But until that happens the code is dead and should be removed.