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: <6050270f-1556-4df3-beab-63e907b28d82@lucifer.local>
Date: Thu, 8 May 2025 17:03:58 +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

I feel we should probably add mm/oom_kill.c, include/linux/mman.h,
mm/internal.h to mm core as a few more key files. What do you think?

We're probably going to be working through a bunch of stragglers for some
time I feel :)

On Thu, May 08, 2025 at 01:23:25PM +0100, Lorenzo Stoakes wrote:
> 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
> >