On Thu, Oct 30, 2025 at 04:25:54PM +0000, Pedro Falcato wrote:

On Wed, Oct 29, 2025 at 04:50:32PM +0000, Lorenzo Stoakes wrote:

quoted

It's useful to be able to force a VMA to be copied on fork outside of the
parameters specified by vma_needs_copy(), which otherwise only copies page
tables if:

* The destination VMA has VM_UFFD_WP set
* The mapping is a PFN or mixed map
* The mapping is anonymous and forked in (i.e. vma->anon_vma is non-NULL)

Setting this flag implies that the page tables mapping the VMA are such
that simply re-faulting the VMA will not re-establish them in identical
form.

We introduce VM_COPY_ON_FORK to clearly identify which flags require this
behaviour, which currently is only VM_MAYBE_GUARD.

Do we want this to be sticky though? If you're looking for more granularity

Yes?

with this flag, the best option might be to stop merges from happening there.

No?

That'd entirely break VMA merging for any VMA you are installing guard regions
into.

That'd be a regression, as the property of guard regions belongs to the page
tables which can propagate across split/merge.

Also, a key purpose of this flag is to be able to correctly propagate page
tables on fork for file-backed VMAs.

Without this we have to install an anon_vma in file-backed VMAs (what we do
now), which has all the same drawbacks.

If not, I can imagine a VMA that merges with other VMAs far past the original
guarded range, and thus you get no granularity (possibly, not even useful).

Err? What? It gets you VMA granularity. You are always going to do better than
'anywhere in the entire mm'. Of course you can imagine scenarios where one VMA
somehow dominates everything, or guard regions are removed etc. but in most
cases you're not going to encounter that.

Also again, the _more important_ purpose here is correct behaviour on fork.

If you're _not_ looking for granularity, then maybe using a per-mm flag for
guard ranges or some other solution would be superior?

I'm not sure what solution you think would be superior that wouldn't involve
significant overhead in having to look up guard regions on split/merge.

This is a property that belongs to the page tables that we're relating to VMAs
which may or may not contain page tables which have this property.

mm granularity would be utterly pointless and leave us with the same anon_vma
hack.

The rest of the patch (superficially) looks good to me, though.

Well there's that at least :)

--
Pedro

Thanks, Lorenzo