1. 05 9月, 2013 1 次提交
  2. 10 7月, 2013 2 次提交
  3. 11 5月, 2013 1 次提交
    • N
      libfc: extend ex_lock to protect all of fc_seq_send · fb00cc23
      Neil Horman 提交于
      This warning was reported recently:
      
      WARNING: at drivers/scsi/libfc/fc_exch.c:478 fc_seq_send+0x14f/0x160 [libfc]()
      (Not tainted)
      Hardware name: ProLiant DL120 G7
      Modules linked in: tcm_fc target_core_iblock target_core_file target_core_pscsi
      target_core_mod configfs dm_round_robin dm_multipath 8021q garp stp llc bnx2fc
      cnic uio fcoe libfcoe libfc scsi_transport_fc scsi_tgt autofs4 sunrpc
      pcc_cpufreq ipv6 hpilo hpwdt e1000e microcode iTCO_wdt iTCO_vendor_support
      serio_raw shpchp ixgbe dca mdio sg ext4 mbcache jbd2 sd_mod crc_t10dif pata_acpi
      ata_generic ata_piix hpsa dm_mirror dm_region_hash dm_log dm_mod [last unloaded:
      scsi_wait_scan]
      Pid: 5464, comm: target_completi Not tainted 2.6.32-272.el6.x86_64 #1
      Call Trace:
       [<ffffffff8106b747>] ? warn_slowpath_common+0x87/0xc0
       [<ffffffff8106b79a>] ? warn_slowpath_null+0x1a/0x20
       [<ffffffffa025f7df>] ? fc_seq_send+0x14f/0x160 [libfc]
       [<ffffffffa035cbce>] ? ft_queue_status+0x16e/0x210 [tcm_fc]
       [<ffffffffa030a660>] ? target_complete_ok_work+0x0/0x4b0 [target_core_mod]
       [<ffffffffa030a766>] ? target_complete_ok_work+0x106/0x4b0 [target_core_mod]
       [<ffffffffa030a660>] ? target_complete_ok_work+0x0/0x4b0 [target_core_mod]
       [<ffffffff8108c760>] ? worker_thread+0x170/0x2a0
       [<ffffffff810920d0>] ? autoremove_wake_function+0x0/0x40
       [<ffffffff8108c5f0>] ? worker_thread+0x0/0x2a0
       [<ffffffff81091d66>] ? kthread+0x96/0xa0
       [<ffffffff8100c14a>] ? child_rip+0xa/0x20
       [<ffffffff81091cd0>] ? kthread+0x0/0xa0
       [<ffffffff8100c140>] ? child_rip+0x0/0x20
      
      It occurs because fc_seq_send can have multiple contexts executing within it at
      the same time, and fc_seq_send doesn't consistently use the ep->ex_lock that
      protects this structure.  Because of that, its possible for one context to clear
      the INIT bit in the ep->esb_state field while another checks it, leading to the
      above stack trace generated by the WARN_ON in the function.
      
      We should probably undertake the effort to convert access to the fc_exch
      structures to use rcu, but that a larger work item.  To just fix this specific
      issue, we can just extend the ex_lock protection through the entire fc_seq_send
      path
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Reported-by: NGris Ge <fge@redhat.com>
      CC: Robert Love <robert.w.love@intel.com>
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      fb00cc23
  4. 20 7月, 2012 3 次提交
  5. 28 3月, 2012 1 次提交
  6. 19 2月, 2012 1 次提交
  7. 16 1月, 2012 1 次提交
  8. 01 11月, 2011 1 次提交
  9. 31 10月, 2011 2 次提交
  10. 03 10月, 2011 1 次提交
  11. 29 8月, 2011 2 次提交
  12. 28 7月, 2011 2 次提交
  13. 30 6月, 2011 1 次提交
    • K
      [SCSI] libfc:Fix for exchange/seq loopup failure when FCoE stack is used as... · e3e65c69
      Kiran Patil 提交于
      [SCSI] libfc:Fix for exchange/seq loopup failure when FCoE stack is used as target and connected to windows initaitor
      
      Problem: Linux based SW target (TCM) connected to windows initiator
      was unable to satisfy write request of size > 2K.
      
      Fix: Existing linux implememtation of FCoE stack is expecting sequence
      number to match w.r.t incoming framme. When DDP is used on target in
      response to write request from initiator, SW stack is notified only
      when last data frame arrives and only the pakcket header of last data
      frame is posted to NetRx queue of storage. When that last packet was
      processed in libfc:Exchange layer, implementation was expecting
      sequence number to match, but in this case sequence number which is
      embedded in FC Header is assigned by windows initaitor, hence due to
      sequence number mismatch post-processing which shall result into
      sending RSP is not done. Enhanced the code to utilize the sequence
      number of incoming last frame and process the packet so that, it will
      eventually complete the write request by sending write response (RSP)
      GOOD.
      
      Notes/Dependencies: This patch is validated using windows and linux
      initiator to make sure, it doesn't break anything.
      Signed-off-by: NKiran Patil <kiran.patil@intel.com>
      Signed-off-by: NRobert Love <robert.w.love@intel.com>
      Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      e3e65c69
  14. 25 5月, 2011 2 次提交
  15. 31 3月, 2011 1 次提交
  16. 01 3月, 2011 2 次提交
  17. 13 2月, 2011 4 次提交
  18. 22 12月, 2010 5 次提交
  19. 28 7月, 2010 3 次提交
  20. 20 7月, 2010 1 次提交
  21. 17 5月, 2010 2 次提交
  22. 12 4月, 2010 1 次提交