linux-kernel - Re: [PATCH] MAINTAINERS: add mm GUP section

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <28428030-1178-469a-a4ab-f1e7179d9106@lucifer.local>
Date: Thu, 8 May 2025 13:23:25 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Uladzislau Rezki <urezki@...il.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jason Gunthorpe <jgg@...dia.com>, John Hubbard <jhubbard@...dia.com>,
        Peter Xu <peterx@...hat.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Vlastimil Babka <vbabka@...e.cz>
Subject: Re: [PATCH] MAINTAINERS: add mm GUP section

On Thu, May 08, 2025 at 10:53:22AM +0200, David Hildenbrand wrote:
> > > > > (looks at vmscan.c)
> > > >
> > > > Current maintainers (mm/unstable) on 20 biggest files in mm, Andrew is
> > > > implicit:
> > > >
> > > >   $ find mm -name "*.c" -type f | xargs wc -l | sort -n -r | head -20
> > > >   198195 total
> > > >     7937 mm/hugetlb.c		# Muchun
> > > >     7881 mm/slub.c		# Christoph/David/Vlastimil
> > > >     7745 mm/vmscan.c		#
> >
> > This is, as Andrew rightly points out, a key one, I will have a look around
> > the git history and put something together here. I'm not sure if we will
> > get an M here, but at least can populate some reviewers.
>
> Yes. I would assume that at least MGLRU people are reviewing this ... and
> probably memcg folks :)

Ack indeed, will try to figure out who best to include.

Will either RFC or send off-list message to coordinate.

>
> [...]
>
> >
> > > >     4703 mm/huge_memory.c	# David
> > > >     4538 mm/filemap.c		# Willy
> > > >     3964 mm/swapfile.c		#
> >
> > The various discussions at LSF lend themselves to suggesting people here,
> > can take a look at this also.
>
> Yes, we should be able to come up with some R.
>
> >
> > > >     3871 mm/ksm.c		#
> >
> > As per discussion below, thanks for suggesting yourself David, I hope this
> > is a case of 'well de facto I am maintaining this'
>
> Yeah, it's exactly that I'm afraid :)

:)) I mean the same in my case also of course. Though far, far fewer
instances for me...

>
> > rather than taking
> > anything new on, as I worry about how much your workload involves :P
> > > I will sniff around the git history too and put something together.
> >
> > > >     3720 mm/gup.c		# David
> > > >     3675 mm/mempolicy.c		#
> >
> > Ack below, and will take a look here also.
> >
> > > >     3371 mm/percpu.c		# Dennis/Tejun/Christoph
> > > >     3370 mm/compaction.c		#
> >
> > As you say lots of R's which is good.
> >
> > As per below would you want M for this?
>
> Probably we'd want a migration section with sth. like
>
> * mm/migrate.c
> * mm/migrate_device.c
> * include/linux/migrate.h
>
> And maybe we also want also the following files in there (a separate section
> might not make sense)
>
> * include/linux/mempolicy.h
> * mm/mempolicy.c
>
>
> MEMORY POLICY AND MIGRATION ? I think I should have the capacity to be M for
> that.

Ack makes sense, will sort something out.

>
>
> mm/compaction.c is a bit in-between the page allocator and migration right
> now, but I think long-term stuff should simply me moved to the proper files
> and compaction.c should be a consumer of migration functionality. And likely
> compaction.c should stay in the "PAGE ALLOCATOR" section.

Ack!

>
> M for "PAGE ALLOCATOR", hmmm ..., I was hoping that Vlastimil might have
> capacity for that? :)

Vlastimil? ;)

I'd certainly support this.

>
>
>
> Not 100% sure what to do with
>
> * include/linux/page_isolation.h
> * mm/page_isolation.c
>
> (I hate the word "page isolation")
>
> They are mostly about page migration (either for alloc_contig... or memory
> hotunplug). Likely they should either go to the MIGRATION section or to the
> PAGE ALLOCATOR? Maybe MIGRATION makes more sense. Thoughts?

I mean it explicitly relates to migrate type and migration so seems to me
it ought to be in migration.

Though migrate type + the machinary around it is a product of the physical
page allocator (I even cover it in the 'physical memory' section of the
book).

I wonder if our soon-to-be page allocator maintainer Vlastimil has
thoughts? ;)

I'd vote for migration though to be honest.

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