1. 28 9月, 2009 1 次提交
  2. 24 9月, 2009 1 次提交
  3. 22 9月, 2009 2 次提交
  4. 16 9月, 2009 3 次提交
  5. 14 9月, 2009 1 次提交
  6. 09 9月, 2009 1 次提交
  7. 03 9月, 2009 1 次提交
    • A
      xfs: xfs_showargs() reports group *and* project quotas enabled · 988abe40
      Alex Elder 提交于
      If you enable group or project quotas on an XFS file system, then the
      mount table presented through /proc/self/mounts erroneously shows
      that both options are in effect for the file system.  The root of
      the problem is some bad logic in the xfs_showargs() function, which
      is used to format the file system type-specific options in effect
      for a file system.
      
      The problem originated in this GIT commit:
          Move platform specific mount option parse out of core XFS code
          Date: 11/22/07
          Author: Dave Chinner
          SHA1 ID: a67d7c5f
      
      For XFS quotas, project and group quota management are mutually
      exclusive--only one can be in effect at a time.  There are two
      parts to managing quotas:  aggregating usage information; and
      enforcing limits.  It is possible to have a quota in effect
      (aggregating usage) but not enforced.
      
      These features are recorded on an XFS mount point using these flags:
          XFS_PQUOTA_ACCT - Project quotas are aggregated
          XFS_GQUOTA_ACCT - Group quotas are aggregated
          XFS_OQUOTA_ENFD - Project/group quotas are enforced
      
      The code in error is in fs/xfs/linux-2.6/xfs_super.c:
      
              if (mp->m_qflags & (XFS_PQUOTA_ACCT|XFS_OQUOTA_ENFD))
                      seq_puts(m, "," MNTOPT_PRJQUOTA);
              else if (mp->m_qflags & XFS_PQUOTA_ACCT)
                      seq_puts(m, "," MNTOPT_PQUOTANOENF);
      
              if (mp->m_qflags & (XFS_GQUOTA_ACCT|XFS_OQUOTA_ENFD))
                      seq_puts(m, "," MNTOPT_GRPQUOTA);
              else if (mp->m_qflags & XFS_GQUOTA_ACCT)
                      seq_puts(m, "," MNTOPT_GQUOTANOENF);
      
      The problem is that XFS_OQUOTA_ENFD will be set in mp->m_qflags
      if either group or project quotas are enforced, and as a result
      both MNTOPT_PRJQUOTA and MNTOPT_GRPQUOTA will be shown as mount
      options.
      Signed-off-by: NAlex Elder <aelder@sgi.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      988abe40
  8. 02 9月, 2009 3 次提交
  9. 01 9月, 2009 1 次提交
  10. 18 8月, 2009 1 次提交
    • C
      xfs: fix locking in xfs_iget_cache_hit · a022fe09
      Christoph Hellwig 提交于
      The locking in xfs_iget_cache_hit currently has numerous problems:
      
       - we clear the reclaim tag without i_flags_lock which protects
         modifications to it
       - we call inode_init_always which can sleep with pag_ici_lock
         held (this is oss.sgi.com BZ #819)
       - we acquire and drop i_flags_lock a lot and thus provide no
         consistency between the various flags we set/clear under it
      
      This patch fixes all that with a major revamp of the locking in
      the function.  The new version acquires i_flags_lock early and
      only drops it once we need to call into inode_init_always or before
      calling xfs_ilock.
      
      This patch fixes a bug seen in the wild where we race modifying the
      reclaim tag.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      Reviewed-by: NEric Sandeen <sandeen@sandeen.net>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      a022fe09
  11. 17 8月, 2009 1 次提交
    • C
      xfs: fix locking in xfs_iget_cache_hit · bc990f5c
      Christoph Hellwig 提交于
      The locking in xfs_iget_cache_hit currently has numerous problems:
      
       - we clear the reclaim tag without i_flags_lock which protects
         modifications to it
       - we call inode_init_always which can sleep with pag_ici_lock
         held (this is oss.sgi.com BZ #819)
       - we acquire and drop i_flags_lock a lot and thus provide no
         consistency between the various flags we set/clear under it
      
      This patch fixes all that with a major revamp of the locking in
      the function.  The new version acquires i_flags_lock early and
      only drops it once we need to call into inode_init_always or before
      calling xfs_ilock.
      
      This patch fixes a bug seen in the wild where we race modifying the
      reclaim tag.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      Reviewed-by: NEric Sandeen <sandeen@sandeen.net>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      bc990f5c
  12. 12 8月, 2009 1 次提交
    • C
      xfs: switch to NOFS allocation under i_lock in xfs_buf_associate_memory · 36fae17a
      Christoph Hellwig 提交于
      xfs_buf_associate_memory is used for setting up the spare buffer for the
      log wrap case in xlog_sync which can happen under i_lock when called from
      xfs_fsync. The i_lock mutex is taken in reclaim context so all allocations
      under it must avoid recursions into the filesystem.  There are a couple
      more uses of xfs_buf_associate_memory in the log recovery code that are
      also affected by this, but I'd rather keep the code simple than passing on
      a gfp_mask argument.  Longer term we should just stop requiring the memoery
      allocation in xlog_sync by some smaller rework of the buffer layer.
      
      Reported by the new reclaim context tracing in lockdep.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      36fae17a
  13. 11 8月, 2009 1 次提交
    • C
      xfs: switch to NOFS allocation under i_lock in xfs_buf_associate_memory · 837273b8
      Christoph Hellwig 提交于
      xfs_buf_associate_memory is used for setting up the spare buffer for the
      log wrap case in xlog_sync which can happen under i_lock when called from
      xfs_fsync. The i_lock mutex is taken in reclaim context so all allocations
      under it must avoid recursions into the filesystem.  There are a couple
      more uses of xfs_buf_associate_memory in the log recovery code that are
      also affected by this, but I'd rather keep the code simple than passing on
      a gfp_mask argument.  Longer term we should just stop requiring the memoery
      allocation in xlog_sync by some smaller rework of the buffer layer.
      
      Reported by the new reclaim context tracing in lockdep.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      837273b8
  14. 31 7月, 2009 3 次提交
  15. 27 7月, 2009 1 次提交
    • E
      xfs: reduce bmv_count in xfs_vn_fiemap · 5c04c78a
      Eric Sandeen 提交于
      commit 6321e3ed caused
      the full bmv_count's worth of getbmapx structures to get
      allocated; telling it to do MAXEXTNUM was a bit insane,
      resulting in ENOMEM every time.
      
      Chop it down to something reasonable, the number of slots
      in the caller's input buffer.  If this is too large the
      caller may get ENOMEM but the reason should not be a
      mystery, and they can try again with something smaller.
      
      We add 1 to the value because in the normal getbmap
      world, bmv_count includes the header and xfs_getbmap does:
      
              nex = bmv->bmv_count - 1;
              if (nex <= 0)
                      return XFS_ERROR(EINVAL);
      Signed-off-by: NEric Sandeen <sandeen@sandeen.net>
      Reviewed-by: NOlaf Weber <olaf@sgi.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      5c04c78a
  16. 13 7月, 2009 1 次提交
  17. 11 7月, 2009 1 次提交
  18. 02 7月, 2009 1 次提交
  19. 24 6月, 2009 1 次提交
  20. 19 6月, 2009 1 次提交
  21. 13 6月, 2009 1 次提交
  22. 12 6月, 2009 1 次提交
  23. 10 6月, 2009 1 次提交
  24. 08 6月, 2009 10 次提交