1. 04 3月, 2010 1 次提交
  2. 25 2月, 2010 1 次提交
  3. 23 2月, 2010 1 次提交
  4. 21 2月, 2010 2 次提交
  5. 20 2月, 2010 2 次提交
  6. 19 2月, 2010 2 次提交
  7. 17 2月, 2010 1 次提交
  8. 16 2月, 2010 1 次提交
    • C
      NFS: Too many GETATTR and ACCESS calls after direct I/O · 65d26953
      Chuck Lever 提交于
      The cached read and write paths initialize fattr->time_start in their
      setup procedures.  The value of fattr->time_start is propagated to
      read_cache_jiffies by nfs_update_inode().  Subsequent calls to
      nfs_attribute_timeout() will then use a good time stamp when
      computing the attribute cache timeout, and squelch unneeded GETATTR
      calls.
      
      Since the direct I/O paths erroneously leave the inode's
      fattr->time_start field set to zero, read_cache_jiffies for that inode
      is set to zero after any direct read or write operation.  This
      triggers an otw GETATTR or ACCESS call to update the file's attribute
      and access caches properly, even when the NFS READ or WRITE replies
      have usable post-op attributes.
      
      Make sure the direct read and write setup code performs the same fattr
      initialization as the cached I/O paths to prevent unnecessary GETATTR
      calls.
      
      This was likely introduced by commit 0e574af1 in 2.6.15, which appears
      to add new nfs_fattr_init() call sites in the cached read and write
      paths, but not in the equivalent places in fs/nfs/direct.c.  A
      subsequent commit in the same series, 33801147, introduces the
      fattr->time_start field.
      
      Interestingly, the direct write reschedule path already has a call to
      nfs_fattr_init() in the right place.
      Reported-by: NQuentin Barnes <qbarnes@yahoo-inc.com>
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Cc: stable@kernel.org
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      65d26953
  9. 15 2月, 2010 1 次提交
  10. 14 2月, 2010 1 次提交
  11. 13 2月, 2010 3 次提交
  12. 12 2月, 2010 4 次提交
  13. 10 2月, 2010 4 次提交
  14. 09 2月, 2010 11 次提交
  15. 08 2月, 2010 1 次提交
    • L
      Fix race in tty_fasync() properly · 80e1e823
      Linus Torvalds 提交于
      This reverts commit 70362511 ("tty: fix race in tty_fasync") and
      commit b04da8bf ("fnctl: f_modown should call write_lock_irqsave/
      restore") that tried to fix up some of the fallout but was incomplete.
      
      It turns out that we really cannot hold 'tty->ctrl_lock' over calling
      __f_setown, because not only did that cause problems with interrupt
      disables (which the second commit fixed), it also causes a potential
      ABBA deadlock due to lock ordering.
      
      Thanks to Tetsuo Handa for following up on the issue, and running
      lockdep to show the problem.  It goes roughly like this:
      
       - f_getown gets filp->f_owner.lock for reading without interrupts
         disabled, so an interrupt that happens while that lock is held can
         cause a lockdep chain from f_owner.lock -> sighand->siglock.
      
       - at the same time, the tty->ctrl_lock -> f_owner.lock chain that
         commit 70362511 introduced, together with the pre-existing
         sighand->siglock -> tty->ctrl_lock chain means that we have a lock
         dependency the other way too.
      
      So instead of extending tty->ctrl_lock over the whole __f_setown() call,
      we now just take a reference to the 'pid' structure while holding the
      lock, and then release it after having done the __f_setown.  That still
      guarantees that 'struct pid' won't go away from under us, which is all
      we really ever needed.
      Reported-and-tested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Acked-by: NGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: NAmérico Wang <xiyou.wangcong@gmail.com>
      Cc: stable@kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      80e1e823
  16. 07 2月, 2010 4 次提交