1. 14 3月, 2012 8 次提交
  2. 13 3月, 2012 15 次提交
  3. 12 3月, 2012 7 次提交
  4. 11 3月, 2012 6 次提交
  5. 10 3月, 2012 4 次提交
    • A
      aio: fix the "too late munmap()" race · c7b28555
      Al Viro 提交于
      Current code has put_ioctx() called asynchronously from aio_fput_routine();
      that's done *after* we have killed the request that used to pin ioctx,
      so there's nothing to stop io_destroy() waiting in wait_for_all_aios()
      from progressing.  As the result, we can end up with async call of
      put_ioctx() being the last one and possibly happening during exit_mmap()
      or elf_core_dump(), neither of which expects stray munmap() being done
      to them...
      
      We do need to prevent _freeing_ ioctx until aio_fput_routine() is done
      with that, but that's all we care about - neither io_destroy() nor
      exit_aio() will progress past wait_for_all_aios() until aio_fput_routine()
      does really_put_req(), so the ioctx teardown won't be done until then
      and we don't care about the contents of ioctx past that point.
      
      Since actual freeing of these suckers is RCU-delayed, we don't need to
      bump ioctx refcount when request goes into list for async removal.
      All we need is rcu_read_lock held just over the ->ctx_lock-protected
      area in aio_fput_routine().
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Acked-by: NBenjamin LaHaise <bcrl@kvack.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c7b28555
    • A
      aio: fix io_setup/io_destroy race · 86b62a2c
      Al Viro 提交于
      Have ioctx_alloc() return an extra reference, so that caller would drop it
      on success and not bother with re-grabbing it on failure exit.  The current
      code is obviously broken - io_destroy() from another thread that managed
      to guess the address io_setup() would've returned would free ioctx right
      under us; gets especially interesting if aio_context_t * we pass to
      io_setup() points to PROT_READ mapping, so put_user() fails and we end
      up doing io_destroy() on kioctx another thread has just got freed...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: NBenjamin LaHaise <bcrl@kvack.org>
      Reviewed-by: NJeff Moyer <jmoyer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      86b62a2c
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 86e06008
      Linus Torvalds 提交于
      Pull btrfs updates from Chris Mason:
       "I have two additional and btrfs fixes in my for-linus branch.  One is
        a casting error that leads to memory corruption on i386 during scrub,
        and the other fixes a corner case in the backref walking code (also
        triggered by scrub)."
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
        Btrfs: fix casting error in scrub reada code
        btrfs: fix locking issues in find_parent_nodes()
      86e06008
    • H
      memcg: revert fix to mapcount check for this release · be22aece
      Hugh Dickins 提交于
      Respectfully revert commit e6ca7b89 "memcg: fix mapcount check
      in move charge code for anonymous page" for the 3.3 release, so that
      it behaves exactly like releases 2.6.35 through 3.2 in this respect.
      
      Horiguchi-san's commit is correct in itself, 1 makes much more sense
      than 2 in that check; but it does not go far enough - swapcount
      should be considered too - if we really want such a check at all.
      
      We appear to have reached agreement now, and expect that 3.4 will
      remove the mapcount check, but had better not make 3.3 different.
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Reviewed-by: NNaoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      be22aece