1. 13 Dec, 2012 3 commits
    • Yi Zou's avatar
      target/tcm_fc: fix the lockdep warning due to inconsistent lock state · 9f4ad44b
      Yi Zou authored
      The lockdep warning below is in theory correct but it will be in really weird
      rare situation that ends up that deadlock since the tcm fc session is hashed
      based the rport id. Nonetheless, the complaining below is about rcu callback
      that does the transport_deregister_session() is happening in softirq, where
      transport_register_session() that happens earlier is not. This triggers the
      lockdep warning below. So, just fix this to make lockdep happy by disabling
      the soft irq before calling transport_register_session() in ft_prli.
      
      BTW, this was found in FCoE VN2VN over two VMs, couple of create and destroy
      would get this triggered.
      
      v1: was enforcing register to be in softirq context which was not righ. See,
      http://www.spinics.net/lists/target-devel/msg03614.html
      
      v2: following comments from Roland&Nick (thanks), it seems we don't have to
      do transport_deregister_session() in rcu callback, so move it into ft_sess_free()
      but still do kfree() of the corresponding ft_sess struct in rcu callback to
      make sure the ft_sess is not freed till the rcu callback.
      
      ...
      [ 1328.370592] scsi2 : FCoE Driver
      [ 1328.383429] fcoe: No FDMI support.
      [ 1328.384509] host2: libfc: Link up on port (000000)
      [ 1328.934229] host2: Assigned Port ID 00a292
      [ 1357.232132] host2: rport 00a393: Remove port
      [ 1357.232568] host2: rport 00a393: Port sending LOGO from Ready state
      [ 1357.233692] host2: rport 00a393: Delete port
      [ 1357.234472] host2: rport 00a393: work event 3
      [ 1357.234969] host2: rport 00a393: callback ev 3
      [ 1357.235979] host2: rport 00a393: Received a LOGO response closed
      [ 1357.236706] host2: rport 00a393: work delete
      [ 1357.237481]
      [ 1357.237631] =================================
      [ 1357.238064] [ INFO: inconsistent lock state ]
      [ 1357.238450] 3.7.0-rc7-yikvm+ #3 Tainted: G           O
      [ 1357.238450] ---------------------------------
      [ 1357.238450] inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
      [ 1357.238450] ksoftirqd/0/3 [HC0[0]:SC1[1]:HE0:SE0] takes:
      [ 1357.238450]  (&(&se_tpg->session_lock)->rlock){+.?...}, at: [<ffffffffa01eacd4>] transport_deregister_session+0x41/0x148 [target_core_mod]
      [ 1357.238450] {SOFTIRQ-ON-W} state was registered at:
      [ 1357.238450]   [<ffffffff810834f5>] mark_held_locks+0x6d/0x95
      [ 1357.238450]   [<ffffffff8108364a>] trace_hardirqs_on_caller+0x12d/0x197
      [ 1357.238450]   [<ffffffff810836c1>] trace_hardirqs_on+0xd/0xf
      [ 1357.238450]   [<ffffffff8149caba>] _raw_spin_unlock_irq+0x2d/0x45
      [ 1357.238450]   [<ffffffffa01e8d10>] __transport_register_session+0xb8/0x122 [target_core_mod]
      [ 1357.238450]   [<ffffffffa01e8dbe>] transport_register_session+0x44/0x5a [target_core_mod]
      [ 1357.238450]   [<ffffffffa018e32c>] ft_prli+0x1e3/0x275 [tcm_fc]
      [ 1357.238450]   [<ffffffffa0160e8d>] fc_rport_recv_req+0x95e/0xdc5 [libfc]
      [ 1357.238450]   [<ffffffffa015be88>] fc_lport_recv_els_req+0xc4/0xd5 [libfc]
      [ 1357.238450]   [<ffffffffa015c778>] fc_lport_recv_req+0x12f/0x18f [libfc]
      [ 1357.238450]   [<ffffffffa015a6d7>] fc_exch_recv+0x8ba/0x981 [libfc]
      [ 1357.238450]   [<ffffffffa0176d7a>] fcoe_percpu_receive_thread+0x47a/0x4e2 [fcoe]
      [ 1357.238450]   [<ffffffff810549f1>] kthread+0xb1/0xb9
      [ 1357.238450]   [<ffffffff814a40ec>] ret_from_fork+0x7c/0xb0
      [ 1357.238450] irq event stamp: 275411
      [ 1357.238450] hardirqs last  enabled at (275410): [<ffffffff810bb6a0>] rcu_process_callbacks+0x229/0x42a
      [ 1357.238450] hardirqs last disabled at (275411): [<ffffffff8149c2f7>] _raw_spin_lock_irqsave+0x22/0x8e
      [ 1357.238450] softirqs last  enabled at (275394): [<ffffffff8103d669>] __do_softirq+0x246/0x26f
      [ 1357.238450] softirqs last disabled at (275399): [<ffffffff8103d6bb>] run_ksoftirqd+0x29/0x62
      [ 1357.238450]
      [ 1357.238450] other info that might help us debug this:
      [ 1357.238450]  Possible unsafe locking scenario:
      [ 1357.238450]
      [ 1357.238450]        CPU0
      [ 1357.238450]        ----
      [ 1357.238450]   lock(&(&se_tpg->session_lock)->rlock);
      [ 1357.238450]   <Interrupt>
      [ 1357.238450]     lock(&(&se_tpg->session_lock)->rlock);
      [ 1357.238450]
      [ 1357.238450]  *** DEADLOCK ***
      [ 1357.238450]
      [ 1357.238450] no locks held by ksoftirqd/0/3.
      [ 1357.238450]
      [ 1357.238450] stack backtrace:
      [ 1357.238450] Pid: 3, comm: ksoftirqd/0 Tainted: G           O 3.7.0-rc7-yikvm+ #3
      [ 1357.238450] Call Trace:
      [ 1357.238450]  [<ffffffff8149399a>] print_usage_bug+0x1f5/0x206
      [ 1357.238450]  [<ffffffff8100da59>] ? save_stack_trace+0x2c/0x49
      [ 1357.238450]  [<ffffffff81082aae>] ? print_irq_inversion_bug.part.14+0x1ae/0x1ae
      [ 1357.238450]  [<ffffffff81083336>] mark_lock+0x106/0x258
      [ 1357.238450]  [<ffffffff81084e34>] __lock_acquire+0x2e7/0xe53
      [ 1357.238450]  [<ffffffff8102903d>] ? pvclock_clocksource_read+0x48/0xb4
      [ 1357.238450]  [<ffffffff810ba6a3>] ? rcu_process_gp_end+0xc0/0xc9
      [ 1357.238450]  [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod]
      [ 1357.238450]  [<ffffffff81085ef1>] lock_acquire+0x119/0x143
      [ 1357.238450]  [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod]
      [ 1357.238450]  [<ffffffff8149c329>] _raw_spin_lock_irqsave+0x54/0x8e
      [ 1357.238450]  [<ffffffffa01eacd4>] ? transport_deregister_session+0x41/0x148 [target_core_mod]
      [ 1357.238450]  [<ffffffffa01eacd4>] transport_deregister_session+0x41/0x148 [target_core_mod]
      [ 1357.238450]  [<ffffffff810bb6a0>] ? rcu_process_callbacks+0x229/0x42a
      [ 1357.238450]  [<ffffffffa018ddc5>] ft_sess_rcu_free+0x17/0x24 [tcm_fc]
      [ 1357.238450]  [<ffffffffa018ddae>] ? ft_sess_free+0x1b/0x1b [tcm_fc]
      [ 1357.238450]  [<ffffffff810bb6d7>] rcu_process_callbacks+0x260/0x42a
      [ 1357.238450]  [<ffffffff8103d55d>] __do_softirq+0x13a/0x26f
      [ 1357.238450]  [<ffffffff8149b34e>] ? __schedule+0x65f/0x68e
      [ 1357.238450]  [<ffffffff8103d6bb>] run_ksoftirqd+0x29/0x62
      [ 1357.238450]  [<ffffffff8105c83c>] smpboot_thread_fn+0x1a5/0x1aa
      [ 1357.238450]  [<ffffffff8105c697>] ? smpboot_unregister_percpu_thread+0x47/0x47
      [ 1357.238450]  [<ffffffff810549f1>] kthread+0xb1/0xb9
      [ 1357.238450]  [<ffffffff8149b49d>] ? wait_for_common+0xbb/0x10a
      [ 1357.238450]  [<ffffffff81054940>] ? __init_kthread_worker+0x59/0x59
      [ 1357.238450]  [<ffffffff814a40ec>] ret_from_fork+0x7c/0xb0
      [ 1357.238450]  [<ffffffff81054940>] ? __init_kthread_worker+0x59/0x59
      [ 1417.440099]  rport-2:0-0: blocked FC remote port time out: removing rport
      Signed-off-by: default avatarYi Zou <yi.zou@intel.com>
      Cc: Open-FCoE <devel@open-fcoe.org>
      Cc: Nicholas A. Bellinger <nab@risingtidesystems.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      9f4ad44b
    • Chris Boot's avatar
      sbp-target: fix error path in sbp_make_tpg() · e1fe2060
      Chris Boot authored
      If the TPG memory is allocated successfully, but we fail further along
      in the function, a dangling pointer to freed memory is left in the TPort
      structure. This is mostly harmless, but does prevent re-trying the
      operation without first removing the TPort altogether.
      Reported-by: default avatarChen Gang <gang.chen@asianux.com>
      Signed-off-by: default avatarChris Boot <bootc@bootc.net>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Nicholas A. Bellinger <nab@linux-iscsi.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      e1fe2060
    • Chris Boot's avatar
      sbp-target: use simple assignment in tgt_agent_rw_agent_state() · 37419d67
      Chris Boot authored
      There is no need to memcpy() a 32-bit integer. The data pointer is
      guaranteed to be quadlet aligned by the FireWire stack so we can replace
      the memcpy() with an assignment.
      
      Thanks to Stefan Richter.
      Signed-off-by: default avatarChris Boot <bootc@bootc.net>
      Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
      Cc: Andy Grover <agrover@redhat.com>
      Cc: Clemens Ladisch <clemens@ladisch.de>
      Cc: Nicholas A. Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      37419d67
  2. 08 Dec, 2012 1 commit
  3. 05 Dec, 2012 3 commits
  4. 28 Nov, 2012 14 commits
  5. 15 Nov, 2012 3 commits
    • Nicholas Bellinger's avatar
      target/iblock: Add WRITE_SAME w/ UNMAP=0 emulation support · f6970ad3
      Nicholas Bellinger authored
      This patch adds support for emulation of WRITE_SAME w/ UNMAP=0 within
      iblock_execute_write_same() backend code.
      
      The emulation uses a bio_add_page() call for each sector, and by default
      enforces a limit of max_write_same_len=0xFFFF (65536) sectors following
      what scsi_debug reports per default for MAXIMUM WRITE SAME LENGTH.
      
      It also sets max_write_same_len to the operational default at setup ->
      iblock_configure_device() time.
      
      (hch: Move unmap logic into iblock_execute_write_same_unmap + add
            check for single sector SGLs in iblock_execute_write_same)
      (mkp: Update comment for 0xFFFF magic constant)
      (nab: drop left-over max_write_same_len check in iblock_execute_write_same)
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      f6970ad3
    • Nicholas Bellinger's avatar
      target: Add/check max_write_same_len device attribute + update block limits VPD · 773cbaf7
      Nicholas Bellinger authored
      This patch adds a new max_write_same_len device attribute for use with
      WRITE_SAME w/ UNMAP=0 backend emulation.  This can be useful for
      lowering the default backend value (IBLOCK uses 0xFFFF).
      
      Also, update block limits VPD emulation code in spc_emulate_evpd_b0() to
      report MAXIMUM WRITE SAME LENGTH, and enforce max_write_same_len during
      sbc_parse() -> sbc_setup_write_same() CDB sanity checking for all emulated
      WRITE_SAME w/ UNMAP=0 cases.
      
      (Robert: Move max_write_same_len check in sbc_setup_write_same() to
               check both WRITE_SAME w/ UNMAP=1 and w/ UNMAP=0 cases)
      
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Cc: Robert Elliott <Elliott@hp.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      773cbaf7
    • Nicholas Bellinger's avatar
      target/sbc: Seperate WRITE_SAME based on UNMAP flag in sbc_ops · cd063bef
      Nicholas Bellinger authored
      This patch adds a new sbc_ops->execute_write_same_unmap() caller for use
      with WRITE_SAME w/ UNMAP=1, and performs the ->execute_cmd() setup based
      this bit within sbc_setup_write_same() code.
      
      Also, makes the changes in sbc_parse_cdb() to handle a sense_reason_t
      return from sbc_setup_write_same() on error.
      Reported-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      cd063bef
  6. 08 Nov, 2012 7 commits
  7. 07 Nov, 2012 9 commits