Messages in this thread | | | Date | Fri, 09 Apr 2010 19:45:11 -0400 | From | Rik van Riel <> | Subject | Re: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmas of a mergeable VMA |
| |
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.
| |