Re: [RFC Patch 0/5] Make anon_vma operations testable

[David Hildenbrand <david@redhat.com>]

On 29.04.25 11:31, Lorenzo Stoakes wrote:
> Wei,
> 
> NACK the whole series.
> 
> I'm really not sure how to get through to you. You were _explicitly_
> advised not to send this series. And yet you've sent it anyway.
> 
> I mean, I appreciate your enthusiasm and the fact you've made tests here
> etc. obviously. And you've clearly put a TON of work in. But I just don't
> know why you would when explicitly told not to without at least discussing
> it first?
> 
> This just isn't a great way of interacting with the community. We're all
> human, please try to have some empathy for others here, as I really do try
> to have with you as best I can.
> 
> This adds a ton of churn and LOCKS IN assumptions about how anon_vma works,
> clashes with other series (most notably series I've been working on), takes
> away from efforts I want to make to start to join file-backed and anon
> reverse mapping logic, separates the two in such a way as to encourage this
> to nonly grow and generally isn't conducive to where I want to go with
> rmap.

anon_vma, the unloved child. :)

I would love to see a simplification that makes it less special, and I 
can understand how adding tests for the ways it is special can be 
counter-productive.

> 
> This is part of why I explicitly told you please don't go down this road,
> because you're likely to end up doing work that doesn't get used. It's not
> a great use of your time either.
> 
> Since there's something useful here in tests, I may at a later date come
> back to those.

Agreed, skimming over the tests there are some nice diagrams and cases.

But I would hope that for most of these cases we could test on a higher 
level: test our expectations when running real programs that we want to 
check, especially when performing internal changes on how we handle anon 
memory + rmap.

E.g., do fork(), then test if we can successfully perform rmap 
lookups/updates (e.g., migrate folio to a different numa node etc).

-- 
Cheers,

David / dhildenb