Messages in this thread | | | Date | Fri, 9 Apr 2010 16:22:19 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [PATCH -v2] rmap: make anon_vma_prepare link in all the anon_vmas of a mergeable VMA |
| |
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?
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.
Linus
| |