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

[Peter Xu <peterx@redhat.com>]

On Mon, Nov 03, 2025 at 09:01:02PM +0100, David Hildenbrand (Red Hat) wrote:
> > > 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".

It was a joke!

uffd_copy() API was NACKed because of this.  Now the new proposal
introduced it.  I made a joke saying Liam allows that to happen in his
branch, but forbid mine.

I thought it was super clear to identify.

> 
> 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.

Sorry, no.  I won't apologize for that.  I was not fair treated, and now I
think it's fair I at least make a joke.  

David, you're leaving, and I'm totally dissappointed that at this point of
time, you ask me to apologize instead.

I thought it was obvious a joke, because I never thought having pmd* in a
function in a module is not OK.

I always thought it was fine, Linux is not a micro kernel.  It's just fine.
It is what happening in Linux right now.  It is so obvious.  In case it was
not clear, I hope I make it clear now.  If I'm going to formally NACK
Liam's series, I won't use this as one of the real reasons.  I just hide it
in some of others that are real reasons.  However if to be fair, when this
reason is removed, this series should also remove the "highlight" that it
removed shmem.h header, because my v1 also did that when with uffd_copy().

> 
> 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.

It's Liam who stood out strongly pushing back what he at least used to be
not familiar with.  This was, IMHO, rude.  It's ok to keep silent on some
patchset that one isn't familiar.  It's ok to ask questions.  It's not ok
to strongly push back without being extremely familiar with the code.

He might be more familiar now, I wish he is. But it's Liam's decision to
work on the code.

We're adults, we do what we should do, not what we asked to do.  If we do
what we asked to do, we should have our reasons.

My ask was trying to make Liam see that what he proposed is over
engineering the whole thing.  I was pretty sure of that, he wasn't.  I
explained to him multiple times on why it was an overkill, he doesn't
agree. It's fine for him to disagree, it's Liam's right.  Then it's also
fine for me to ask him code it up to notice himself, if I can't persuade
him.  That's the only way for him to persuade me instead.

I sincerely wished that works out.  As I said, then I'll properly review
it, and then we build whatever we need on top.  I'm totally fine.  However
it didn't go like that, the API is exactly what I pictured.  I prefer my
proposal.  That's what I did: showing the difference when there're two
proposals, and ask for a second opinion.

It's not fair to put that on top of me to blame.  He's trying to justify
he's correct.  It has nothing to do with me.  He can stop pushing back
anytime.  He can keep proposing what he works on.  It's his decision, not
mine.

> 
> 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 ...)

We've got some second opinion from Mike, please read it first.  David,
you're co-maintaining mm with Andrew.  I think it's fair indeed you provide
how things should go together with Andrew.  It's fair you and Andrew
whoever would like to make a decision on how to move forward.  I'm fine on
whatever decision you want to make.

I think I tried my best trying to make gmem work as simple as possible.

For the CoC report, I wish someone from CoC would also review it.

Thanks,

-- 
Peter Xu