1. 10 Mar, 2012 5 commits
    • Jan Kara's avatar
      udf: Fix deadlock in udf_release_file() · f6940fe9
      Jan Kara authored
      udf_release_file() can be called from munmap() path with mmap_sem held.  Thus
      we cannot take i_mutex there because that ranks above mmap_sem. Luckily,
      i_mutex is not needed in udf_release_file() anymore since protection by
      i_data_sem is enough to protect from races with write and truncate.
      Reported-by: default avatarAl Viro <viro@ZenIV.linux.org.uk>
      Reviewed-by: default avatarNamjae Jeon <linkinjeon@gmail.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      f6940fe9
    • Tyler Hicks's avatar
      vfs: Correctly set the dir i_mutex lockdep class · 978d6d8c
      Tyler Hicks authored
      9a7aa12f introduced additional logic around setting the i_mutex
      lockdep class for directory inodes. The idea was that some filesystems
      may want their own special lockdep class for different directory
      inodes and calling unlock_new_inode() should not clobber one of
      those special classes.
      
      I believe that the added conditional, around the *negated* return value
      of lockdep_match_class(), caused directory inodes to be placed in the
      wrong lockdep class.
      
      inode_init_always() sets the i_mutex lockdep class with i_mutex_key for
      all inodes. If the filesystem did not change the class during inode
      initialization, then the conditional mentioned above was false and the
      directory inode was incorrectly left in the non-directory lockdep class.
      If the filesystem did set a special lockdep class, then the conditional
      mentioned above was true and that class was clobbered with
      i_mutex_dir_key.
      
      This patch removes the negation from the conditional so that the i_mutex
      lockdep class is properly set for directory inodes. Special classes are
      preserved and directory inodes with unmodified classes are set with
      i_mutex_dir_key.
      Signed-off-by: default avatarTyler Hicks <tyhicks@canonical.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      978d6d8c
    • Al Viro's avatar
      aio: fix the "too late munmap()" race · c7b28555
      Al Viro authored
      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: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Acked-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      c7b28555
    • Al Viro's avatar
      aio: fix io_setup/io_destroy race · 86b62a2c
      Al Viro authored
      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: default avatarAl Viro <viro@zeniv.linux.org.uk>
      Acked-by: default avatarBenjamin LaHaise <bcrl@kvack.org>
      Reviewed-by: default avatarJeff Moyer <jmoyer@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      86b62a2c
    • Linus Torvalds's avatar
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs · 86e06008
      Linus Torvalds authored
      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
  2. 09 Mar, 2012 14 commits
  3. 08 Mar, 2012 16 commits
  4. 07 Mar, 2012 5 commits