Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 09 2月, 2017 1 次提交
    • Q
      qla2xxx: Add framework for async fabric discovery · 726b8548
      由 Quinn Tran 提交于 
      Currently code performs a full scan of the fabric for
every RSCN. Its an expensive process in a noisy large SAN.

This patch optimizes expensive fabric discovery process by
scanning switch for the affected port when RSCN is received.

Currently Initiator Mode code makes login/logout decision without
knowledge of target mode. This causes driver and firmware to go
out-of-sync. This framework synchronizes both initiator mode
personality and target mode personality in making login/logout
decision.

This patch adds following capabilities in the driver

- Send Notification Acknowledgement asynchronously.
- Update session/fcport state asynchronously.
- Create a session or fcport struct asynchronously.
- Send GNL asynchronously. The command will ask FW to
  provide a list of FC Port entries FW knows about.
- Send GPDB asynchronously. The command will ask FW to
  provide detail data of an FC Port FW knows about or
  perform ADISC to verify the state of the session.
- Send GPNID asynchronously. The command will ask switch
  to provide WWPN for provided NPort ID.
- Send GPSC asynchronously. The command will ask switch
  to provide registered port speed for provided WWPN.
- Send GIDPN asynchronously. The command will ask the
  switch to provide Nport ID for provided WWPN.
- In driver unload path, schedule all session for deletion
  and wait for deletion to complete before allowing driver
  unload to proceed.
Signed-off-by: NQuinn Tran <quinn.tran@cavium.com>
Signed-off-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
[ bvanassche: fixed spelling in patch description ]
Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      726b8548
  3. 18 1月, 2017 1 次提交
  5. 10 1月, 2017 1 次提交
    • M
      scsi: qla2xxx: Get mutex lock before checking optrom_state · c7702b8c
      由 Milan P. Gandhi 提交于 
      There is a race condition with qla2xxx optrom functions where one thread
might modify optrom buffer, optrom_state while other thread is still
reading from it.

In couple of crashes, it was found that we had successfully passed the
following 'if' check where we confirm optrom_state to be
QLA_SREADING. But by the time we acquired mutex lock to proceed with
memory_read_from_buffer function, some other thread/process had already
modified that option rom buffer and optrom_state from QLA_SREADING to
QLA_SWAITING. Then we got ha->optrom_buffer 0x0 and crashed the system:

        if (ha->optrom_state != QLA_SREADING)
                return 0;

        mutex_lock(&ha->optrom_mutex);
        rval = memory_read_from_buffer(buf, count, &off, ha->optrom_buffer,
            ha->optrom_region_size);
        mutex_unlock(&ha->optrom_mutex);

With current optrom function we get following crash due to a race
condition:

[ 1479.466679] BUG: unable to handle kernel NULL pointer dereference at           (null)
[ 1479.466707] IP: [<ffffffff81326756>] memcpy+0x6/0x110
[...]
[ 1479.473673] Call Trace:
[ 1479.474296]  [<ffffffff81225cbc>] ? memory_read_from_buffer+0x3c/0x60
[ 1479.474941]  [<ffffffffa01574dc>] qla2x00_sysfs_read_optrom+0x9c/0xc0 [qla2xxx]
[ 1479.475571]  [<ffffffff8127e76b>] read+0xdb/0x1f0
[ 1479.476206]  [<ffffffff811fdf9e>] vfs_read+0x9e/0x170
[ 1479.476839]  [<ffffffff811feb6f>] SyS_read+0x7f/0xe0
[ 1479.477466]  [<ffffffff816964c9>] system_call_fastpath+0x16/0x1b

Below patch modifies qla2x00_sysfs_read_optrom,
qla2x00_sysfs_write_optrom functions to get the mutex_lock before
checking ha->optrom_state to avoid similar crashes.

The patch was applied and tested and same crashes were no longer
observed again.
Tested-by: NMilan P. Gandhi <mgandhi@redhat.com>
Signed-off-by: NMilan P. Gandhi <mgandhi@redhat.com>
Reviewed-by: NLaurence Oberman <loberman@redhat.com>
Acked-by: NHimanshu Madhani <himanshu.madhani@cavium.com>
Signed-off-by: NMartin K. Petersen <martin.petersen@oracle.com>
      c7702b8c
  7. 15 12月, 2016 1 次提交
  9. 16 7月, 2016 4 次提交
  11. 24 2月, 2016 3 次提交
  13. 08 1月, 2016 1 次提交
  15. 27 8月, 2015 3 次提交
  17. 25 7月, 2015 1 次提交
  19. 25 9月, 2014 4 次提交
  21. 19 5月, 2014 3 次提交
  23. 20 3月, 2014 1 次提交
  25. 16 3月, 2014 3 次提交
  27. 19 1月, 2014 1 次提交
  29. 19 12月, 2013 4 次提交
  31. 03 9月, 2013 5 次提交
  33. 09 7月, 2013 1 次提交
    • C
      [SCSI] qla2xxx: Do not query FC statistics during chip reset. · 8fbfe2d2
      由 Chad Dupuis 提交于 
      During a chip reset, the mailbox call to get FC statistics from the ISP will
not work resulting in needless mailbox accesses and errors printing out:

qla2xxx [0000:05:00.0]-00af:11: Performing ISP error recovery - ha=ffff881fad044800.
qla2xxx [0000:05:00.0]-1020:11: **** Failed mbx[0]=4001, mb[1]=4953, mb[2]=5020, mb[3]=b100, cmd=6d ****.
qla2xxx [0000:05:00.0]-1020:11: **** Failed mbx[0]=4001, mb[1]=4953, mb[2]=5020, mb[3]=b100, cmd=6d ****.
qla2xxx [0000:05:00.0]-1020:11: **** Failed mbx[0]=4001, mb[1]=4953, mb[2]=5020, mb[3]=b100, cmd=6d ****.
qla2xxx [0000:05:00.0]-1020:11: **** Failed mbx[0]=4001, mb[1]=4953, mb[2]=5020, mb[3]=b100, cmd=6d ****.
qla2xxx [0000:05:00.0]-1020:11: **** Failed mbx[0]=4001, mb[1]=4953, mb[2]=5020, mb[3]=b100, cmd=6d ****.

To prevent this, check for a chip reset when an application queries for FC
stats and return immediately if a chip reset is occurring.
Signed-off-by: NChad Dupuis <chad.dupuis@qlogic.com>
Signed-off-by: NSaurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: NJames Bottomley <JBottomley@Parallels.com>
      8fbfe2d2
  35. 12 4月, 2013 1 次提交
  37. 06 4月, 2013 1 次提交