1. 10 2月, 2010 3 次提交
  2. 08 2月, 2010 2 次提交
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6 · 6339204e
      Linus Torvalds 提交于
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs-2.6:
        Take ima_file_free() to proper place.
        ima: rename PATH_CHECK to FILE_CHECK
        ima: rename ima_path_check to ima_file_check
        ima: initialize ima before inodes can be allocated
        fix ima breakage
        Take ima_path_check() in nfsd past dentry_open() in nfsd_open()
        freeze_bdev: don't deactivate successfully frozen MS_RDONLY sb
        befs: fix leak
      6339204e
    • 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
  3. 07 2月, 2010 12 次提交
  4. 06 2月, 2010 7 次提交
  5. 05 2月, 2010 16 次提交