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: <565d955d-6797-4c41-bd98-10fd5aca3374@lucifer.local>
Date: Tue, 4 Nov 2025 07:10:22 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Peter Xu <peterx@...hat.com>
Cc: "David Hildenbrand (Red Hat)" <david@...nel.org>,
        "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

Peter,

I feel like this is getting entirely out of hand.

You have three mm maintainers telling you that you've crossed the line,
with respect - might I suggest that's an indication that you in fact have?

This is perhaps the result of some level of miscommunication resulting in
your being defensive due to you misinterpreting good faith technical
feedback based on genuine concerns as some form of attack.

They are not, and have never been. A couple instances of exasperated
reference to UFFD code in need of cleaning up (something you admit to
yourself) does not amount to this, sorry.

I find your comments about 'familiarity' deeply disturbing - UFFD is hooked
into all of mm including VMA logic, page table logic, in fact a lot of the
issue with the code is that it's coupled in this way - experienced mm
maintainers' opinons are _entirely_ valid as as result.

But in any case - you ought to engage on the technical points. A blanket
dismissal is wholly inappropriate. If somebody's 'unfamiliarity' with parts
of the code base are an issue, then you should very trivially be able to
push back on the points raised right?

The issue here is non-technical, having experienced it myself, and as
exemplified in this thread - people provide valid criticism, you respond by
essentially refusing to engage on the points raised.

The net result is exactly what's happened here - Liam has (entirely
understandably) decided to no longer engage with the thread.

I've not been engaging on this review either - It's not that I'm bowled
over by the technical arguments, it's that it's not worth the effort
sitting down and assessing the technical merits because what's the point?
You don't accept technical criticism and I don't review/maintain this code
so am not obliged to.

Your desire for a '2nd opinion' seems to be more so desiring that people
agree with you. You have received a 2nd opinion. You didn't like it so now
you want another.

Your series will likely now land with review comments unaddressed having
silenced criticism through non-technical means.

Rather than all of this nonsense, we could simply have had a technical
debate - with strong feelings on both sides perhaps - but constrained to
the technical issues at hand.

Instead we are now going to end up merging code where criticism has been
silenced.

Again I question if this is how things should work in mm or the
kernel. Perhaps something to discuss at the next LSF/MM.

Regards, Lorenzo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ