linux-kernel - Re: [PATCH] MAINTAINERS: group all VMA-related files into the VMA 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: <dfe6b339-a742-4adc-9a53-c653510428d8@lucifer.local>
Date: Tue, 10 Dec 2024 09:51:04 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Jann Horn <jannh@...gle.com>, Vlastimil Babka <vbabka@...e.cz>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MAINTAINERS: group all VMA-related files into the VMA
 section

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