1. 25 8月, 2012 2 次提交
    • J
      xfs: Remove type argument from xfs_seek_data()/xfs_seek_hole() · 834ab122
      Jeff Liu 提交于
      The type is already indicated by the function naming explicitly, so this argument
      can be omitted from those calls.
      Signed-off-by: NJie Liu <jeff.liu@oracle.com>
      Reviewed-by: NMark Tinguely <tinguely@sgi.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      834ab122
    • C
      xfs: fix race while discarding buffers [V4] · e599b325
      Carlos Maiolino 提交于
      While xfs_buftarg_shrink() is freeing buffers from the dispose list (filled with
      buffers from lru list), there is a possibility to have xfs_buf_stale() racing
      with it, and removing buffers from dispose list before xfs_buftarg_shrink() does
      it.
      
      This happens because xfs_buftarg_shrink() handle the dispose list without
      locking and the test condition in xfs_buf_stale() checks for the buffer being in
      *any* list:
      
      if (!list_empty(&bp->b_lru))
      
      If the buffer happens to be on dispose list, this causes the buffer counter of
      lru list (btp->bt_lru_nr) to be decremented twice (once in xfs_buftarg_shrink()
      and another in xfs_buf_stale()) causing a wrong account usage of the lru list.
      
      This may cause xfs_buftarg_shrink() to return a wrong value to the memory
      shrinker shrink_slab(), and such account error may also cause an underflowed
      value to be returned; since the counter is lower than the current number of
      items in the lru list, a decrement may happen when the counter is 0, causing
      an underflow on the counter.
      
      The fix uses a new flag field (and a new buffer flag) to serialize buffer
      handling during the shrink process. The new flag field has been designed to use
      btp->bt_lru_lock/unlock instead of xfs_buf_lock/unlock mechanism.
      
      dchinner, sandeen, aquini and aris also deserve credits for this.
      Signed-off-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Reviewed-by: NBen Myers <bpm@sgi.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      e599b325
  2. 17 8月, 2012 4 次提交
    • T
      xfs: check for possible overflow in xfs_ioc_trim · 643bfc06
      Tomas Racek 提交于
      If range.start or range.minlen is bigger than filesystem size, return
      invalid value error. This fixes possible overflow in BTOBB macro when
      passed value was nearly ULLONG_MAX.
      Signed-off-by: NTomas Racek <tracek@redhat.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      643bfc06
    • C
      xfs: unlock the AGI buffer when looping in xfs_dialloc · c4982110
      Christoph Hellwig 提交于
      Also update some commens in the area to make the code easier to read.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NMark Tinguely <tinguely@sgi.com>
      Reviewed-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      c4982110
    • A
      xfs: kill struct declarations in xfs_mount.h · 1ed845df
      Alex Elder 提交于
      I noticed that "struct xfs_mount_args" was still declared in
      "fs/xfs/xfs_mount.h".  That struct doesn't even exist any more (and
      is obviously not referenced elsewhere in that header file).  While
      in there, delete four other unneeded struct declarations in that
      file.
      
      Doing so highlights that "fs/xfs/xfs_trace.h" was relying indirectly
      on "xfs_mount.h" to be #included in order to declare "struct
      xfs_bmbt_irec", so add that declaration to resolve that issue.
      Signed-off-by: NAlex Elder <elder@inktank.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      1ed845df
    • D
      xfs: fix uninitialised variable in xfs_rtbuf_get() · a76cccbe
      Dave Chinner 提交于
      Results in this assert failure in generic/090:
      
      XFS: Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4363
      .....
      Call Trace:
       [<ffffffff814680db>] xfs_bmapi_read+0x6b/0x370
       [<ffffffff814b64b2>] xfs_rtbuf_get+0x42/0x130
       [<ffffffff814b6f09>] xfs_rtget_summary+0x89/0x120
       [<ffffffff814b7bfe>] xfs_rtallocate_extent_size+0xce/0x340
       [<ffffffff814b89f0>] xfs_rtallocate_extent+0x240/0x290
       [<ffffffff81462c1a>] xfs_bmap_rtalloc+0x1ba/0x340
       [<ffffffff81463a65>] xfs_bmap_alloc+0x35/0x40
       [<ffffffff8146f111>] xfs_bmapi_allocate+0xf1/0x350
       [<ffffffff8146f9de>] xfs_bmapi_write+0x66e/0xa60
       [<ffffffff8144538a>] xfs_iomap_write_direct+0x22a/0x3f0
       [<ffffffff8143707b>] __xfs_get_blocks+0x38b/0x5d0
       [<ffffffff814372d4>] xfs_get_blocks_direct+0x14/0x20
       [<ffffffff811b0081>] do_blockdev_direct_IO+0xf71/0x1eb0
       [<ffffffff811b1015>] __blockdev_direct_IO+0x55/0x60
       [<ffffffff814355ca>] xfs_vm_direct_IO+0x11a/0x1e0
       [<ffffffff8112d617>] generic_file_direct_write+0xd7/0x1b0
       [<ffffffff8143e16c>] xfs_file_dio_aio_write+0x13c/0x320
       [<ffffffff8143e6f2>] xfs_file_aio_write+0x1c2/0x1d0
       [<ffffffff81174a07>] do_sync_write+0xa7/0xe0
       [<ffffffff81175288>] vfs_write+0xa8/0x160
       [<ffffffff81175702>] sys_pwrite64+0x92/0xb0
       [<ffffffff81b68f69>] system_call_fastpath+0x16/0x1b
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Signed-off-by: NBen Myers <bpm@sgi.com>
      a76cccbe
  3. 03 8月, 2012 1 次提交
    • S
      ceph: simplify+fix atomic_open · 5ef50c3b
      Sage Weil 提交于
      The initial ->atomic_open op was carried over from the old intent code,
      which was incomplete and didn't really work.  Replace it with a fresh
      method.  In particular:
      
       * always attempt to do an atomic open+lookup, both for the create case
         and for lookups of existing files.
       * fix symlink handling by returning 1 to the VFS so that we can follow
         the link to its destination. This fixes a longstanding ceph bug (#2392).
      Signed-off-by: NSage Weil <sage@inktank.com>
      5ef50c3b
  4. 02 8月, 2012 1 次提交
  5. 01 8月, 2012 9 次提交
  6. 31 7月, 2012 23 次提交