1. 15 Mar, 2012 3 commits
    • Dave Chinner's avatar
      xfs: fallback to vmalloc for large buffers in xfs_attrmulti_attr_get · ad650f5b
      Dave Chinner authored
      xfsdump uses for a large buffer for extended attributes, which has a
      kmalloc'd shadow buffer in the kernel. This can fail after the
      system has been running for some time as it is a high order
      allocation. Add a fallback to vmalloc so that it doesn't require
      contiguous memory and so won't randomly fail while xfsdump is
      running.
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Reviewed-by: default avatarMark Tinguely <tinguely@sgi.com>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      ad650f5b
    • Dave Chinner's avatar
      6eb24660
    • Dave Chinner's avatar
      xfs: fix inode lookup race · f30d500f
      Dave Chinner authored
      When we get concurrent lookups of the same inode that is not in the
      per-AG inode cache, there is a race condition that triggers warnings
      in unlock_new_inode() indicating that we are initialising an inode
      that isn't in a the correct state for a new inode.
      
      When we do an inode lookup via a file handle or a bulkstat, we don't
      serialise lookups at a higher level through the dentry cache (i.e.
      pathless lookup), and so we can get concurrent lookups of the same
      inode.
      
      The race condition is between the insertion of the inode into the
      cache in the case of a cache miss and a concurrently lookup:
      
      Thread 1			Thread 2
      xfs_iget()
        xfs_iget_cache_miss()
          xfs_iread()
          lock radix tree
          radix_tree_insert()
      				rcu_read_lock
      				radix_tree_lookup
      				lock inode flags
      				XFS_INEW not set
      				igrab()
      				unlock inode flags
      				rcu_read_unlock
      				use uninitialised inode
      				.....
          lock inode flags
          set XFS_INEW
          unlock inode flags
          unlock radix tree
        xfs_setup_inode()
          inode flags = I_NEW
          unlock_new_inode()
            WARNING as inode flags != I_NEW
      
      This can lead to inode corruption, inode list corruption, etc, and
      is generally a bad thing to occur.
      
      Fix this by setting XFS_INEW before inserting the inode into the
      radix tree. This will ensure any concurrent lookup will find the new
      inode with XFS_INEW set and that forces the lookup to wait until the
      XFS_INEW flag is removed before allowing the lookup to succeed.
      
      cc: <stable@vger.kernel.org> # for 3.0.x, 3.2.x
      Signed-off-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      f30d500f
  2. 14 Mar, 2012 6 commits
  3. 13 Mar, 2012 5 commits
  4. 05 Mar, 2012 3 commits
  5. 29 Feb, 2012 3 commits
  6. 25 Feb, 2012 1 commit
    • Alex Elder's avatar
      xfs: only take the ILOCK in xfs_reclaim_inode() · ad637a10
      Alex Elder authored
      At the end of xfs_reclaim_inode(), the inode is locked in order to
      we wait for a possible concurrent lookup to complete before the
      inode is freed.  This synchronization step was taking both the ILOCK
      and the IOLOCK, but the latter was causing lockdep to produce
      reports of the possibility of deadlock.
      
      It turns out that there's no need to acquire the IOLOCK at this
      point anyway.  It may have been required in some earlier version of
      the code, but there should be no need to take the IOLOCK in
      xfs_iget(), so there's no (longer) any need to get it here for
      synchronization.  Add an assertion in xfs_iget() as a reminder
      of this assumption.
      
      Dave Chinner diagnosed this on IRC, and Christoph Hellwig suggested
      no longer including the IOLOCK.  I just put together the patch.
      Signed-off-by: default avatarAlex Elder <elder@dreamhost.com>
      Reviewed-by: default avatarDave Chinner <dchinner@redhat.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      ad637a10
  7. 23 Feb, 2012 13 commits
  8. 21 Feb, 2012 2 commits
  9. 13 Feb, 2012 1 commit
  10. 10 Feb, 2012 1 commit
    • Christoph Hellwig's avatar
      xfs: use a normal shrinker for the dquot freelist · 92b2e5b3
      Christoph Hellwig authored
      Stop reusing dquots from the freelist when allocating new ones directly, and
      implement a shrinker that actually follows the specifications for the
      interface.  The shrinker implementation is still highly suboptimal at this
      point, but we can gradually work on it.
      
      This also fixes an bug in the previous lock ordering, where we would take
      the hash and dqlist locks inside of the freelist lock against the normal
      lock ordering.  This is only solvable by introducing the dispose list,
      and thus not when using direct reclaim of unused dquots for new allocations.
      
      As a side-effect the quota upper bound and used to free ratio values in
      /proc/fs/xfs/xqm are set to 0 as these values don't make any sense in the
      new world order.
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBen Myers <bpm@sgi.com>
      
      (cherry picked from commit 04da0c81)
      92b2e5b3
  11. 03 Feb, 2012 2 commits