[lkml]   [2010]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 1/2] mm,migration: Prevent rmap_walk_[anon|ksm] seeing the wrong VMA information

On Wed, 5 May 2010, Linus Torvalds wrote:
> From the vma, it's simply
> avc = list_entry(vma->anon_vma_chain.prev, struct anon_vma_chain, same_vma);
> anon_vma = avc->anon_vma;
> and once you take that lock, you know you've gotten the lock for all
> chains related to that page. We _know_ that every single vma that is
> associated with that anon_vma must have a chain that eventually ends in
> that entry.

To clarify: here "is associated with that anon_vma" is basically about the
whole forest of anon_vma/vma links. Different vma's can be associated with
different anon_vma's, and pages can be associated with anon_vma's that can
in turn reach other anon_vma's and many other vma's.

But regardless of _how_ you walk the chains between anon_vma's and vma's
(including walking "back-pointers" that don't even exist except
conceptually for the pointer going the other way), any relationship will
have started at _some_ root vma.

IOW, the root anon_vma is directly 1:1 related to "do these vma/anon_vma's
relate in _any_ way". If it's the same root anon_vma, then there is a
historical relationship. And if the root anon_vma's are different, then
there cannot be any relationship at all.

So locking the root anon_vma is both minimal _and_ sufficient. Any locking
scheme (traversing the lists) would eventually end up hitting that root
entry (minimal locking), and at the same time that root entry is also
guaranteed to be the same for all related entities (ie it's sufficient to
lock the root entry if everybody else also looks up their root and locks

I think. Tell me if I'm wrong.


 \ /
  Last update: 2010-05-05 20:03    [W:0.135 / U:0.104 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site