linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: David Hildenbrand <david@redhat.com>
Cc: Jann Horn <jannh@google.com>, Vlastimil Babka <vbabka@suse.cz>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MAINTAINERS: group all VMA-related files into the VMA section
Date: Tue, 10 Dec 2024 09:51:04 +0000	[thread overview]
Message-ID: <dfe6b339-a742-4adc-9a53-c653510428d8@lucifer.local> (raw)
In-Reply-To: <a3cacdde-8dab-4dcb-a720-9e00833ee9c1@redhat.com>

David,

To avoid an infinite back-and-forth...

I think you're stuck on the idea that we are sat in a VMA 'vacuum', perhaps
because I put so much effort into separating out the VMA logic, for the
purpose of being able to userland test it, it's almost given the wrong
impression (I should perhaps have put less effort into this? :)

But we have for quite some time now de facto been expected to maintain all
aspects of mapping, remapping, etc. INCLUDING page table considerations.

We are more or less de facto maintaining all that (modulo madvise.c - I
grant you this is the odd one out).

So you can imagine it's a bit frustrating, when that's the case, to be told
in effect - no this isn't for you - right?

For instance, as I said before, we have spent large parts of the 6.12 cycle
dealing with practical concerns specifically around page table
manipulation.

Maintainership is more than setting up lei rules, obviously. One can set
lei rules for anything. It means that our say has more impact, and it also
means that we are (co-)responsible for the listed files, and that's acked
rather than disregarded.

So, again, I politely disagree with your assessment re: page tables.

I think their manipulation under circumstances where you
map/remap/mprotect/mlock is -inseparable- from memory mapping/VMA
logic. Otherwise, what's the point right?

My suggestion is that:

a. we put everything in MEMORY MAPPING
b. We drop mm/madvise.c from the list

I'm more than happy to hear your suggestions however. But whatever your
view won't change the de facto situation, it only makes it more difficult
for us to do what is already expected of us...

But I'd also like - given your strong push back - to remind you - this is
not a coup :) we are simply co-maintainers with Andrew, we don't send a PR
to Linus, the <2.5% of mm code this change represents would not be our sole
domain...

Thanks, Lorenzo


  reply	other threads:[~2024-12-10  9:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-06 19:16 Lorenzo Stoakes
2024-12-06 19:35 ` Liam R. Howlett
2024-12-09  9:16 ` David Hildenbrand
2024-12-09 10:06   ` Lorenzo Stoakes
2024-12-09 14:09     ` David Hildenbrand
2024-12-09 14:28       ` Lorenzo Stoakes
2024-12-09 14:56         ` David Hildenbrand
2024-12-09 15:04           ` Lorenzo Stoakes
2024-12-09 13:25   ` Vlastimil Babka
2024-12-09 14:00     ` David Hildenbrand
2024-12-09 14:11       ` Lorenzo Stoakes
2024-12-09 14:25         ` David Hildenbrand
2024-12-09 14:38         ` Jann Horn
2024-12-09 14:44           ` David Hildenbrand
2024-12-09 14:45           ` Lorenzo Stoakes
2024-12-09 15:03             ` David Hildenbrand
2024-12-09 15:16               ` Lorenzo Stoakes
2024-12-09 22:02                 ` David Hildenbrand
2024-12-10  9:51                   ` Lorenzo Stoakes [this message]
2024-12-10 16:59                     ` David Hildenbrand
2024-12-11  9:35                       ` Lorenzo Stoakes
2024-12-11 10:27                         ` David Hildenbrand
2024-12-11 10:44                           ` Lorenzo Stoakes
2024-12-10 16:06                   ` Liam R. Howlett
2024-12-09 14:32 ` Lorenzo Stoakes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dfe6b339-a742-4adc-9a53-c653510428d8@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=jannh@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox