Re: [LSF/MM/BPF TOPIC] The Future of the Anonymous Reverse Mapping [RESEND]

[Rik van Riel <riel@surriel.com>]

On Sat, 2026-05-02 at 07:53 +0100, Lorenzo Stoakes wrote:
> As is time-honoured LSF tradition, I am sharing code for my proposal.
> 
> I worked a very long day yesterday and got the _very_ rough PoC code
> into
> some kind of vaguely shareable state.
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/ljs/linux.git/log/?h=project/cow-context
> 
> CAVEATS:
> 
> * The code is not great, it's 'experimental, wave your arms, hope for
> the
>   best' stuff used for experimentation.

First, some refcounting that confuses me.

The changelog, and the code in dup_cow_context
shows that only the parent's cow context gets
an increased refcount.

However, the code in __put_cow_context seems
to unconditionally decrement refcounts all up
the hierarchy, instead of bailing out once it
encounters a parent that still has a non-zero
refcount.

How is that supposed to work?

Now, having the remaps array cloned at fork
time does make the refcounting on that side
a lot simpler. I like that.

However, it does raise another question.

Say we have process A, with child process B.

Process A has memory mapped at address X.

Process B munmaps memory at address X, and
then maps new memory at address X.

If I haven't missed something important, the
remap table does not need to get used, because 
the offset and the virtual address match.

How does the COW walk handle that situation?

Overall, I like that you are trying to tackle
the problems associated with anon_vma, but
have to wonder if this implementation will
be able to avoid some of the complexity 
inherent in the problem space.

-- 
All Rights Reversed.