1. 01 9月, 2009 1 次提交
  2. 12 8月, 2009 2 次提交
  3. 02 7月, 2009 1 次提交
  4. 10 6月, 2009 1 次提交
  5. 30 4月, 2009 1 次提交
    • L
      xfs_file_last_byte() needs to acquire ilock · def6b3ba
      Lachlan McIlroy 提交于
      We had some systems crash with this stack:
      
      [<a00000010000cb20>] ia64_leave_kernel+0x0/0x280
      [<a00000021291ca00>] xfs_bmbt_get_startoff+0x0/0x20 [xfs]
      [<a0000002129080b0>] xfs_bmap_last_offset+0x210/0x280 [xfs]
      [<a00000021295b010>] xfs_file_last_byte+0x70/0x1a0 [xfs]
      [<a00000021295b200>] xfs_itruncate_start+0xc0/0x1a0 [xfs]
      [<a0000002129935f0>] xfs_inactive_free_eofblocks+0x290/0x460 [xfs]
      [<a000000212998fb0>] xfs_release+0x1b0/0x240 [xfs]
      [<a0000002129ad930>] xfs_file_release+0x70/0xa0 [xfs]
      [<a000000100162ea0>] __fput+0x1a0/0x420
      [<a000000100163160>] fput+0x40/0x60
      
      The problem here is that xfs_file_last_byte() does not acquire the
      inode lock and can therefore race with another thread that is modifying
      the extext list.  While xfs_bmap_last_offset() is trying to lookup
      what was the last extent some extents were merged and the extent list
      shrunk so the index we lookup is now beyond the end of the extent list
      and potentially in a freed buffer.
      Signed-off-by: NLachlan McIlroy <lmcilroy@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      def6b3ba
  6. 29 4月, 2009 1 次提交
    • L
      xfs_file_last_byte() needs to acquire ilock · f25181f5
      Lachlan McIlroy 提交于
      We had some systems crash with this stack:
      
      [<a00000010000cb20>] ia64_leave_kernel+0x0/0x280
      [<a00000021291ca00>] xfs_bmbt_get_startoff+0x0/0x20 [xfs]
      [<a0000002129080b0>] xfs_bmap_last_offset+0x210/0x280 [xfs]
      [<a00000021295b010>] xfs_file_last_byte+0x70/0x1a0 [xfs]
      [<a00000021295b200>] xfs_itruncate_start+0xc0/0x1a0 [xfs]
      [<a0000002129935f0>] xfs_inactive_free_eofblocks+0x290/0x460 [xfs]
      [<a000000212998fb0>] xfs_release+0x1b0/0x240 [xfs]
      [<a0000002129ad930>] xfs_file_release+0x70/0xa0 [xfs]
      [<a000000100162ea0>] __fput+0x1a0/0x420
      [<a000000100163160>] fput+0x40/0x60
      
      The problem here is that xfs_file_last_byte() does not acquire the
      inode lock and can therefore race with another thread that is modifying
      the extext list.  While xfs_bmap_last_offset() is trying to lookup
      what was the last extent some extents were merged and the extent list
      shrunk so the index we lookup is now beyond the end of the extent list
      and potentially in a freed buffer.
      Signed-off-by: NLachlan McIlroy <lmcilroy@redhat.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NFelix Blyakher <felixb@sgi.com>
      Signed-off-by: NFelix Blyakher <felixb@sgi.com>
      f25181f5
  7. 19 1月, 2009 3 次提交
  8. 16 1月, 2009 1 次提交
  9. 22 12月, 2008 1 次提交
  10. 11 12月, 2008 1 次提交
    • C
      [XFS] resync headers with libxfs · 6d73cf13
      Christoph Hellwig 提交于
       - xfs_sb.h add the XFS_SB_VERSION2_PARENTBIT features2 that has been
         around in userspace for some time
       - xfs_inode.h: move a few things out of __KERNEL__ that are needed by
         userspace
       - xfs_mount.h: only include xfs_sync.h under __KERNEL__
       - xfs_inode.c: minor whitespace fixup.  I accidentaly changes this when
         importing this file for use by userspace.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      6d73cf13
  11. 10 12月, 2008 1 次提交
  12. 04 12月, 2008 2 次提交
  13. 01 12月, 2008 9 次提交
  14. 17 11月, 2008 1 次提交
    • D
      [XFS] Fix double free of log tickets · cc09c0dc
      Dave Chinner 提交于
      When an I/O error occurs during an intermediate commit on a rolling
      transaction, xfs_trans_commit() will free the transaction structure
      and the related ticket. However, the duplicate transaction that
      gets used as the transaction continues still contains a pointer
      to the ticket. Hence when the duplicate transaction is cancelled
      and freed, we free the ticket a second time.
      
      Add reference counting to the ticket so that we hold an extra
      reference to the ticket over the transaction commit. We drop the
      extra reference once we have checked that the transaction commit
      did not return an error, thus avoiding a double free on commit
      error.
      
      Credit to Nick Piggin for tripping over the problem.
      
      SGI-PV: 989741
      Signed-off-by: NDave Chinner <david@fromorbit.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      cc09c0dc
  15. 10 11月, 2008 1 次提交
    • L
      [XFS] Wait for all I/O on truncate to zero file size · 2cf7f0da
      Lachlan McIlroy 提交于
      It's possible to have outstanding xfs_ioend_t's queued when the file size
      is zero. This can happen in the direct I/O path when a direct I/O write
      fails due to ENOSPC. In this case the xfs_ioend_t will still be queued (ie
      xfs_end_io_direct() does not know that the I/O failed so can't force the
      xfs_ioend_t to be flushed synchronously).
      
      When we truncate a file on unlink we don't know to wait for these
      xfs_ioend_ts and we can have a use-after-free situation if the inode is
      reclaimed before the xfs_ioend_t is finally processed.
      
      As was suggested by Dave Chinner lets wait for all I/Os to complete when
      truncating the file size to zero.
      
      SGI-PV: 981668
      
      SGI-Modid: xfs-linux-melb:xfs-kern:32216a
      Signed-off-by: NLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: NChristoph Hellwig <hch@infradead.org>
      2cf7f0da
  16. 30 10月, 2008 13 次提交