linux-kernel - Re: [PATCH v4 0/4] mm/userfaultfd: modulize memory types

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: <7768bbb5-f060-45f7-b584-95bd73c47146@kernel.org>
Date: Mon, 3 Nov 2025 21:01:02 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Peter Xu <peterx@...hat.com>, Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 David Hildenbrand <david@...hat.com>, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, Mike Rapoport <rppt@...nel.org>,
 Muchun Song <muchun.song@...ux.dev>, Nikita Kalyazin <kalyazin@...zon.com>,
 Vlastimil Babka <vbabka@...e.cz>, Axel Rasmussen <axelrasmussen@...gle.com>,
 Andrew Morton <akpm@...ux-foundation.org>,
 James Houghton <jthoughton@...gle.com>, Hugh Dickins <hughd@...gle.com>,
 Michal Hocko <mhocko@...e.com>, Ujwal Kundur <ujwal.kundur@...il.com>,
 Oscar Salvador <osalvador@...e.de>, Suren Baghdasaryan <surenb@...gle.com>,
 Andrea Arcangeli <aarcange@...hat.com>, conduct@...nel.org
Subject: Re: [PATCH v4 0/4] mm/userfaultfd: modulize memory types

>> I have an extremely heavy workload at the moment anyway, but honestly
>> interactions like this have seriously put me off being involved in this review
>> personally.
>>
>> Do we really want this to be how review in mm or the kernel is?
>>
>> Is that really the culture we want to have here?
> 
> Gosh.. Seriously?
> 
> I'm ok if this needs to be audited.  I have all the previous discussions in
> the cover letter as links.

I'm late to the party (or whatever this here is called. ah right, 
drama), and I haven't yet dug through all the emails and certainly not 
through all the of involved code changes.

Peter, I was a bit surprised by your messages here indeed, not what I 
expected.

The "Your code allows to operate on pmd* in a module??? That's too risky 
and mm can explode!  Isn't it?" definitely was absolutely unnecessary 
... or telling Liam that "he want almost mad".

Again, not what I would have expected from you, and I would assume that 
you had a bad day and would at least apologize now that some time passed.

I understand that you were upset by the previous feedback on the earlier 
series.

There were some heated arguments in the last discussions, but most of 
them were based on misunderstandings. I would have thought that once 
they were resolved that we could continue focusing on discussing the 
technical details again.

 From what I can see you asked for actual code and when Liam came back 
with some code that looks like *a lot of work* to me.

He really seems to care (which I highly appreciate) and went the extra 
mile to show us how the uffd code could evolve.

We've all (well okay, some of us) been crying for some proper 
userfaultfd cleanups for years.

So is there a way we can move forward with this without thinking in 
binary? Is there some middle-ground to be had? Can some reworks come on 
top of your series? Can so reworks be integrated in this series?

I agree that what Liam proposes here is on the larger side, and probably 
does a lot of things in a single rework. That doesn't mean that we 
couldn't move into that direction in smaller steps.

(I really don't think we should be thinking in terms of a CoC war like: 
show them what I did and I will show them what they did. We are all 
working on the same bigger goal here after all ...)

-- 
Cheers

David