1. 17 Sep, 2008 5 commits
    • David Chinner's avatar
      [XFS] Prevent lockdep false positives when locking two inodes. · f9114eba
      David Chinner authored
      If we call xfs_lock_two_inodes() to grab both the iolock and the ilock,
      then drop the ilocks on both inodes, then grab them again (as
      xfs_swap_extents() does) then lockdep will report a locking order problem.
      This is a false positive.
      
      To avoid this, disallow xfs_lock_two_inodes() fom locking both inode locks
      at once - force calers to make two separate calls. This means that nested
      dropping and regaining of the ilocks will retain the same lockdep subclass
      and so lockdep will not see anything wrong with this code.
      
      SGI-PV: 986238
      
      SGI-Modid: xfs-linux-melb:xfs-kern:31999a
      Signed-off-by: default avatarDavid Chinner <david@fromorbit.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarPeter Leckie <pleckie@sgi.com>
      Signed-off-by: default avatarLachlan McIlroy <lachlan@sgi.com>
      f9114eba
    • David Chinner's avatar
      [XFS] Fix barrier status change detection. · b5b8c9ac
      David Chinner authored
      The current code in xlog_iodone() uses the wrong macro to check if the
      barrier has been cleared due to an EOPNOTSUPP error form the lower layer.
      
      SGI-PV: 986143
      
      SGI-Modid: xfs-linux-melb:xfs-kern:31984a
      Signed-off-by: default avatarDavid Chinner <david@fromorbit.com>
      Signed-off-by: default avatarNathaniel W. Turner <nate@houseofnate.net>
      Signed-off-by: default avatarPeter Leckie <pleckie@sgi.com>
      Signed-off-by: default avatarLachlan McIlroy <lachlan@sgi.com>
      b5b8c9ac
    • Lachlan McIlroy's avatar
      [XFS] Prevent direct I/O from mapping extents beyond eof · 364f358a
      Lachlan McIlroy authored
      With the help from some tracing I found that we try to map extents beyond
      eof when doing a direct I/O read. It appears that the way to inform the
      generic direct I/O path (ie do_direct_IO()) that we have breached eof is
      to return an unmapped buffer from xfs_get_blocks_direct(). This will cause
      do_direct_IO() to jump to the hole handling code where is will check for
      eof and then abort.
      
      This problem was found because a direct I/O read was trying to map beyond
      eof and was encountering delayed allocations. The delayed allocations
      beyond eof are speculative allocations and they didn't get converted when
      the direct I/O flushed the file because there was only enough space in the
      current AG to convert and write out the dirty pages within eof. Note that
      xfs_iomap_write_allocate() wont necessarily convert all the delayed
      allocation passed to it - it will return after allocating the first extent
      - so if the delayed allocation extends beyond eof then it will stay that
      way.
      
      SGI-PV: 983683
      
      SGI-Modid: xfs-linux-melb:xfs-kern:31929a
      Signed-off-by: default avatarLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@infradead.org>
      364f358a
    • Christoph Hellwig's avatar
      [XFS] Fix regression introduced by remount fixup · 6efdf281
      Christoph Hellwig authored
      Logically we would return an error in xfs_fs_remount code to prevent users
      from believing they might have changed mount options using remount which
      can't be changed.
      
      But unfortunately mount(8) adds all options from mtab and fstab to the
      mount arguments in some cases so we can't blindly reject options, but have
      to check for each specified option if it actually differs from the
      currently set option and only reject it if that's the case.
      
      Until that is implemented we return success for every remount request, and
      silently ignore all options that we can't actually change.
      
      SGI-PV: 985710
      
      SGI-Modid: xfs-linux-melb:xfs-kern:31908a
      Signed-off-by: default avatarChristoph Hellwig <hch@infradead.org>
      Signed-off-by: default avatarTim Shimmin <tes@sgi.com>
      Signed-off-by: default avatarLachlan McIlroy <lachlan@sgi.com>
      6efdf281
    • Lachlan McIlroy's avatar
      [XFS] Move memory allocations for log tracing out of the critical path · 31bd61f2
      Lachlan McIlroy authored
      Memory allocations for log->l_grant_trace and iclog->ic_trace are done on
      demand when the first event is logged. In xlog_state_get_iclog_space() we
      call xlog_trace_iclog() under a spinlock and allocating memory here can
      cause us to sleep with a spinlock held and deadlock the system.
      
      For the log grant tracing we use KM_NOSLEEP but that means we can lose
      trace entries. Since there is no locking to serialize the log grant
      tracing we could race and have multiple allocations and leak memory.
      
      So move the allocations to where we initialize the log/iclog structures.
      Use KM_NOFS to avoid recursing into the filesystem and drop log->l_trace
      since it's not even used.
      
      SGI-PV: 983738
      
      SGI-Modid: xfs-linux-melb:xfs-kern:31896a
      Signed-off-by: default avatarLachlan McIlroy <lachlan@sgi.com>
      Signed-off-by: default avatarChristoph Hellwig <hch@infradead.org>
      31bd61f2
  2. 15 Sep, 2008 1 commit
  3. 14 Sep, 2008 1 commit
  4. 13 Sep, 2008 33 commits