1. 09 11月, 2016 16 次提交
  2. 19 8月, 2016 1 次提交
  3. 14 7月, 2016 1 次提交
    • C
      libfc: sanity check cpu number extracted from xid · fa068832
      Chris Leech 提交于
      In the receive path libfc extracts a cpu number from the ox_id in the
      fiber channel header and uses that to do a per_cpu_ptr conversion.  If,
      for some reason, a frame is received with an invalid ox_id, per_cpu_ptr
      will return an invalid pointer and the libfc receive path will panic the
      system trying to use it.
      
      I'm currently looking at such a case, and I don't yet know why a cpu
      number > nr_cpu_ids is appearing in an exchange id.  But adding a sanity
      check in libfc prevents a system panic, and seems like good idea when
      dealing with frames coming in from the network.
      Signed-off-by: NChris Leech <cleech@redhat.com>
      Acked-by: NJohannes Thumshirn <jth@kernel.org>
      Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      fa068832
  4. 13 8月, 2015 1 次提交
  5. 05 9月, 2013 9 次提交
  6. 10 7月, 2013 2 次提交
  7. 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
  8. 20 7月, 2012 3 次提交
  9. 28 3月, 2012 1 次提交
  10. 19 2月, 2012 1 次提交
  11. 16 1月, 2012 1 次提交
  12. 01 11月, 2011 1 次提交
  13. 31 10月, 2011 2 次提交