Re: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmasof a mergeable VMA

[Rik van Riel]

On 04/09/2010 07:22 PM, Linus Torvalds wrote:
> On Fri, 9 Apr 2010, Johannes Weiner wrote:
> > +	/*
> > +	 * 1. case: vma and next are split parts of one root vma.
> > +	 * Their anon_vma_chain is equal and we can drop that of next.
> > +	 *
> > +	 * 2. case: one vma was instantiated as mergeable with the
> > +	 * other one and inherited the other one's primary anon_vma as
> > +	 * the singleton in its chain.
> > +	 *
> > +	 * If next came after vma, vma's chain is already an unstrict
> > +	 * superset of next's and we can treat it like case 1.
> > +	 *
> > +	 * If vma has the singleton chain, we have to copy next's
> > +	 * unique anon_vmas over.
> > +	 */
>
> This comment makes my head hurt. In fact, the whole anon_vma thing hurts
> my head.
>
> Can we have some better high-level documentation on what happens for all
> the cases.
>
>   - split (mprotect, or munmap in the middle):
>
> 	anon_vma_clone: the two vma's will have the same anon_vma, and the
> 	anon_vma chains will be equivalent.
>
>   - merge (mprotect that creates a mergeable state):
>
> 	anon_vma_merge: we're supposed to have a anon_vma_chain that is
> 	a superset of the two chains of the merged entries.
>
>   - fork:
>
> 	anon_vma_fork: each new vma will have a _new_ anon_vma as it's
> 	primary one, and will link to the old primary trough the
> 	anon_vma_chain. It's doing this with a anon_vma_clone() followed
> 	by adding an entra entry to the new anon_vma, and setting
> 	vma->anon_vma to the new one.
>
>   - create/mmap:
>
> 	anon_vma_prepare: find a mergeable anon_vma and use that as a
> 	singleton, because the other entries on the anon_vma chain won't
> 	matter, since they cannot be associated with any pages associated
> 	with the newly created vma..
>
> Correct?

This is indeed correct.

> Quite frankly, just looking at that, I can't see how we get to your rules.
> At least not trivially. Especially with multiple merges, I don't see
> how "singleton" is such a special case.

The trick is in the fact that anon_vma_merge is only called
when vma->anon_vma == vma1->anon_vma.

If the top anon_vmas are different, then anon_vma_merge will
not be called.

This means that VMAs which have recently passed through fork
will not be passed to anon_vma_merge, because their top
anon_vmas are different.

That leaves just the split & create cases, which will be
passed to anon_vma_merge when they are merged.

In case of split, they will have identical anon_vma chains.

In case of create + merge, one of the two VMAs will have
the whole anon_vma chain, while the other one has just
the top anon_vma.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/