Thread (140 messages) 140 messages, 10 authors, 13d ago

Re: [PATCH 09/30] mm/rmap: parameterise anon_vma_interval_tree_*() by anon_vma

From: Lorenzo Stoakes <ljs@kernel.org>
Date: 2026-06-30 15:59:49
Also in: damon, dri-devel, kvm, linux-arm-msm, linux-fsdevel, linux-iommu, linux-mm, linux-perf-users, linux-tegra, lkml, nvdimm

On Tue, Jun 30, 2026 at 11:55:12AM -0400, Gregory Price wrote:
On Tue, Jun 30, 2026 at 04:49:45PM +0100, Lorenzo Stoakes wrote:
quoted
On Tue, Jun 30, 2026 at 11:46:46AM -0400, Gregory Price wrote:
quoted
On Mon, Jun 29, 2026 at 01:23:20PM +0100, Lorenzo Stoakes wrote:
quoted
Similar to what we did with mapping_interval_tree*(), let's declare
anon_vma_interval_tree*() in terms of anon_vma rather than rb_root_cached.

In each case the rb tree referenced is &anon_vma->rb_root, so just pass
anon_vma and the functions can figure this out themselves.

Additionally, rename 'node' to 'avc', 'index' to 'pgoff_start', and 'last'
to 'pgoff_last' to make clear what is being passed.
would it be possible to split the pure rename changes out from the
changed function declarations?  It's hard to pick out this as something
that needs to be looked at as more than just a %s/x/y/
Hmmm do I have to? :P
I mean, no :]
quoted
I mean sure I can on a respin potentially, but it is a
pretty trivial change? Just mechnically as above.
And yeah certainly not worth a respin.  Just learning some of the
friction points of reviewing as I spend a little more time doing it
every day.
Oh in the end you will be driven absolutely insane, David and I are already
there and soon you will join us! :) <- nervous smiley

But yeah, sorry if that made it harder to track what I'm doing here! Usually I
really try to split up to make each patch as easy as possibel to review, but
this one I thought 'why not at the same time' :P
~Gregory
Cheers, Lorenzo
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help