1. 13 Apr, 2010 3 commits
    • Linus Torvalds's avatar
      anon_vma: clone the anon_vma chain in the right order · 646d87b4
      Linus Torvalds authored
      We want to walk the chain in reverse order when cloning it, so that the
      order of the result chain will be the same as the order in the source
      chain.  When we add entries to the chain, they go at the head of the
      chain, so we want to add the source head last.
      Reviewed-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Tested-by: Borislav Petkov <bp@alien8.de> [ "No, it still oopses" ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      646d87b4
    • Linus Torvalds's avatar
      vma_adjust: fix the copying of anon_vma chains · 287d97ac
      Linus Torvalds authored
      When we move the boundaries between two vma's due to things like
      mprotect, we need to make sure that the anon_vma of the pages that got
      moved from one vma to another gets properly copied around.  And that was
      not always the case, in this rather hard-to-follow code sequence.
      
      Clarify the code, and fix it so that it copies the anon_vma from the
      right source.
      Reviewed-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Tested-by: Borislav Petkov <bp@alien8.de> [ "Yeah, not so much this one either" ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      287d97ac
    • Linus Torvalds's avatar
      Simplify and comment on anon_vma re-use for anon_vma_prepare() · d0e9fe17
      Linus Torvalds authored
      This changes the anon_vma reuse case to require that we only reuse
      simple anon_vma's - ie the case when the vma only has a single anon_vma
      associated with it.
      
      This means that a reuse of an anon_vma from an adjacent vma will always
      guarantee that both vma's are associated not only with the same
      anon_vma, they will also have the same anon_vma chain (of just a single
      entry in this case).
      
      And since anon_vma re-use was the only case where the same anon_vma
      might be associated with different chains of anon_vma's, we now have the
      case that every vma that shares the same anon_vma will always also have
      the same chain.  That makes it much easier to think about merging vma's
      that share the same anon_vma's: you can always just drop the other
      anon_vma chain in anon_vma_merge() since you know that they are always
      identical.
      
      This also splits up the function to validate the anon_vma re-use, and
      adds a lot of commentary about the possible races.
      Reviewed-by: default avatarRik van Riel <riel@redhat.com>
      Acked-by: default avatarJohannes Weiner <hannes@cmpxchg.org>
      Tested-by: Borislav Petkov <bp@alien8.de> [ "That didn't fix it" ]
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d0e9fe17
  2. 09 Apr, 2010 37 commits