1. 09 2月, 2010 4 次提交
    • F
      [SCSI] compat_ioct: fix bsg SG_IO · 84eb8fb4
      FUJITA Tomonori 提交于
      bsg's SG_IO doesn't work on 32-bit userspace and 64-bit kernelspace.
      
      The problem is that both sg and bsg drivers use SG_IO
      ioctl. sg_ioctl_trans() does 32/64-bit conversion even against bsg
      header. It messes up bsg header. bsg driver gets garbage.
      
      This patch fixes sg_ioctl_trans to handle only sg header (struct
      sg_io_hdr).
      Reported-by: NGiridhar Malavali <giridhar.malavali@qlogic.com>
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      84eb8fb4
    • X
      [SCSI] qla2xxx: make msix interrupt handler safe for irq · 0f19bc68
      Xiaotian Feng 提交于
      Yinghai has reported a lockdep warning on qla2xxx:
      
      [   77.965784] WARNING: at kernel/lockdep.c:2332
      trace_hardirqs_on_caller+0xc6/0x14b()
      [   77.977492] Hardware name: Sun
      [   77.979485] Modules linked in:
      [   77.994337] Pid: 0, comm: swapper Not tainted
      2.6.33-rc4-tip-yh-03949-g3a8e3f5-dirty #64
      [   78.000120] Call Trace:
      [   78.013298]  <IRQ>  [<ffffffff81076b54>] warn_slowpath_common+0x7c/0x94
      [   78.017746]  [<ffffffff81cd712c>] ? _raw_spin_unlock_irq+0x30/0x36
      [   78.035171]  [<ffffffff81076b80>] warn_slowpath_null+0x14/0x16
      [   78.040152]  [<ffffffff810a2ae8>] trace_hardirqs_on_caller+0xc6/0x14b
      [   78.055400]  [<ffffffff810a2b7a>] trace_hardirqs_on+0xd/0xf
      [   78.058951]  [<ffffffff81cd712c>] _raw_spin_unlock_irq+0x30/0x36
      [   78.074889]  [<ffffffff816461ef>] qla24xx_msix_default+0x243/0x281
      [   78.091598]  [<ffffffff810a5752>] ? __lock_release+0xa5/0xae
      [   78.096799]  [<ffffffff810c02ae>] handle_IRQ_event+0x53/0x113
      [   78.111568]  [<ffffffff810c2061>] handle_edge_irq+0xf3/0x13b
      [   78.116255]  [<ffffffff81035109>] handle_irq+0x24/0x2f
      [   78.132063]  [<ffffffff81cdc4b4>] do_IRQ+0x5c/0xc3
      [   78.134684]  [<ffffffff81cd7393>] ret_from_intr+0x0/0xf
      [   78.137903]  <EOI>  [<ffffffff81039a56>] ? mwait_idle+0xaf/0xbb
      [   78.155674]  [<ffffffff81039a4d>] ? mwait_idle+0xa6/0xbb
      [   78.158600]  [<ffffffff81031c7c>] cpu_idle+0x61/0xa1
      [   78.174333]  [<ffffffff81c85d7a>] rest_init+0x7e/0x80
      [   78.178122]  [<ffffffff82832d1f>] start_kernel+0x316/0x31d
      [   78.193623]  [<ffffffff82832297>] x86_64_start_reservations+0xa7/0xab
      [   78.198924]  [<ffffffff8283237f>] x86_64_start_kernel+0xe4/0xeb
      [   78.214540] ---[ end trace be4529f30a2e4ef5 ]---
      
      This was happened when qla2xxx msix interrupt handler is trying to enable
      IRQs by spin_unlock_irq(). We should make interrupt handler safe for IRQs,
      use spin_lock_irqsave/spin_unlock_irqrestore, this will not break the IRQs
      status in interrupt handler.
      Reported-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NXiaotian Feng <dfeng@redhat.com>
      Acked-by: NGiridhar Malavali <giridhar.malavali@qlogic.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      0f19bc68
    • S
      [SCSI] zfcp: Report FC BSG errors in correct field · 7dec9cf1
      Swen Schillig 提交于
      The status FC_CTELS_STATUS_REJECT for all FC BSG errors is not
      appropriate. Instead, report -EIO in the result field if there was a
      problem in zfcp with the FC BSG request. If the request is good from
      our point of view, report result 0, status FC_CTELS_STATUS_OK and let
      userspace read the Accept or Reject from the payload (as documented in
      scsi_bsg_fc.h).
      Signed-off-by: NSwen Schillig <swen@vnet.ibm.com>
      Signed-off-by: NChristof Schmitt <christof.schmitt@de.ibm.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      7dec9cf1
    • K
      [SCSI] mptfusion : mptscsih_abort return value should be SUCCESS instead of value 0. · 9858ae38
      Kashyap, Desai 提交于
      retval should be SUCCESS/FAILED which is defined at scsi.h
      retval = 0 is directing wrong return value. It must be retval = SUCCESS.
      Signed-off-by: NKashyap Desai <kashyap.desai@lsi.com>
      Signed-off-by: NJames Bottomley <James.Bottomley@suse.de>
      9858ae38
  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 15 次提交