summaryrefslogtreecommitdiff
path: root/drivers/scsi/libfc/fc_rport.c
AgeCommit message (Collapse)AuthorFilesLines
2020-10-30scsi: libfc: Move scsi/fc_encode.h to libfcArnd Bergmann1-1/+1
Most of this file is only used inside of libfc, so move it to where it is actually used, with only fc_fill_fc_hdr() left inside of the header. Link: https://lore.kernel.org/r/20201026160705.3706396-1-arnd@kernel.org Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-08-24treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva1-1/+1
Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
2020-08-07Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds1-2/+2
Pull SCSI updates from James Bottomley: "This consists of the usual driver updates (ufs, qla2xxx, tcmu, lpfc, hpsa, zfcp, scsi_debug) and minor bug fixes. We also have a huge docbook fix update like most other subsystems and no major update to the core (the few non trivial updates are either minor fixes or removing an unused feature [scsi_sdb_cache])" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (307 commits) scsi: scsi_transport_srp: Sanitize scsi_target_block/unblock sequences scsi: ufs-mediatek: Apply DELAY_AFTER_LPM quirk to Micron devices scsi: ufs: Introduce device quirk "DELAY_AFTER_LPM" scsi: virtio-scsi: Correctly handle the case where all LUNs are unplugged scsi: scsi_debug: Implement tur_ms_to_ready parameter scsi: scsi_debug: Fix request sense scsi: lpfc: Fix typo in comment for ULP scsi: ufs-mediatek: Prevent LPM operation on undeclared VCC scsi: iscsi: Do not put host in iscsi_set_flashnode_param() scsi: hpsa: Correct ctrl queue depth scsi: target: tcmu: Make TMR notification optional scsi: target: tcmu: Implement tmr_notify callback scsi: target: tcmu: Fix and simplify timeout handling scsi: target: tcmu: Factor out new helper ring_insert_padding scsi: target: tcmu: Do not queue aborted commands scsi: target: tcmu: Use priv pointer in se_cmd scsi: target: Add tmr_notify backend function scsi: target: Modify core_tmr_abort_task() scsi: target: iscsi: Fix inconsistent debug message scsi: target: iscsi: Fix login error when receiving ...
2020-07-15scsi: libfc: Fix a couple of misdocumented function parametersLee Jones1-2/+2
Fixes the following W=1 kernel build warning(s): drivers/scsi/libfc/fc_rport.c:129: warning: Function parameter or member 'port_id' not described in 'fc_rport_create' drivers/scsi/libfc/fc_rport.c:129: warning: Excess function parameter 'ids' description in 'fc_rport_create' drivers/scsi/libfc/fc_rport.c:1452: warning: Function parameter or member 'rdata_arg' not described in 'fc_rport_logo_resp' drivers/scsi/libfc/fc_rport.c:1452: warning: Excess function parameter 'lport_arg' description in 'fc_rport_logo_resp' Link: https://lore.kernel.org/r/20200713074645.126138-12-lee.jones@linaro.org Cc: Hannes Reinecke <hare@suse.de> Reviewed-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-06-27scsi: libfc: Skip additional kref updating work eventJaved Hasan1-4/+5
When an rport event (RPORT_EV_READY) is updated without work being queued, avoid taking an additional reference. This issue was leading to memory leak. Trace from KMEMLEAK tool: unreferenced object 0xffff8888259e8780 (size 512): comm "kworker/2:1", jiffies 4433237386 (age 113021.971s) hex dump (first 32 bytes): 58 0a ec cf 83 88 ff ff 00 00 00 00 00 00 00 00 01 00 00 00 08 00 00 00 13 7d f0 1e 0e 00 00 10 backtrace: [<000000006b25760f>] fc_rport_recv_req+0x3c6/0x18f0 [libfc] [<00000000f208d994>] fc_lport_recv_els_req+0x120/0x8a0 [libfc] [<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc] [<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc] [<00000000ad5be37b>] qedf_ll2_process_skb+0x73d/0xad0 [qedf] [<00000000e0eb6893>] process_one_work+0x382/0x6c0 [<000000002dfd9e21>] worker_thread+0x57/0x5c0 [<00000000b648204f>] kthread+0x1a0/0x1c0 [<0000000072f5ab20>] ret_from_fork+0x35/0x40 [<000000001d5c05d8>] 0xffffffffffffffff Below is the log sequence which leads to memory leak. Here we get the RPORT_EV_READY and RPORT_EV_STOP back to back, which lead to overwrite the event RPORT_EV_READY by event RPORT_EV_STOP. Because of this, kref_count gets incremented by 1. kernel: host0: rport fffce5: Received PLOGI request kernel: host0: rport fffce5: Received PLOGI in INIT state kernel: host0: rport fffce5: Port is Ready kernel: host0: rport fffce5: Received PRLI request while in state Ready kernel: host0: rport fffce5: PRLI rspp type 8 active 1 passive 0 kernel: host0: rport fffce5: Received LOGO request while in state Ready kernel: host0: rport fffce5: Delete port kernel: host0: rport fffce5: Received PLOGI request kernel: host0: rport fffce5: Received PLOGI in state Delete - send busy kernel: host0: rport fffce5: work event 3 kernel: host0: rport fffce5: lld callback ev 3 kernel: host0: rport fffce5: work delete Link: https://lore.kernel.org/r/20200626094959.32151-1-jhasan@marvell.com Reviewed-by: Girish Basrur <gbasrur@marvell.com> Reviewed-by: Saurav Kashyap <skashyap@marvell.com> Reviewed-by: Shyam Sundar <ssundar@marvell.com> Signed-off-by: Javed Hasan <jhasan@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-06-27scsi: libfc: Handling of extra krefJaved Hasan1-1/+3
Handling of extra kref which is done by lookup table in case rdata is already present in list. This issue was leading to memory leak. Trace from KMEMLEAK tool: unreferenced object 0xffff8888259e8780 (size 512): comm "kworker/2:1", pid 182614, jiffies 4433237386 (age 113021.971s) hex dump (first 32 bytes): 58 0a ec cf 83 88 ff ff 00 00 00 00 00 00 00 00 01 00 00 00 08 00 00 00 13 7d f0 1e 0e 00 00 10 backtrace: [<000000006b25760f>] fc_rport_recv_req+0x3c6/0x18f0 [libfc] [<00000000f208d994>] fc_lport_recv_els_req+0x120/0x8a0 [libfc] [<00000000a9c437b8>] fc_lport_recv+0xb9/0x130 [libfc] [<00000000ad5be37b>] qedf_ll2_process_skb+0x73d/0xad0 [qedf] [<00000000e0eb6893>] process_one_work+0x382/0x6c0 [<000000002dfd9e21>] worker_thread+0x57/0x5c0 [<00000000b648204f>] kthread+0x1a0/0x1c0 [<0000000072f5ab20>] ret_from_fork+0x35/0x40 [<000000001d5c05d8>] 0xffffffffffffffff Below is the log sequence which leads to memory leak. Here we get the nested "Received PLOGI request" for same port and this request leads to call the fc_rport_create() twice for the same rport. kernel: host1: rport fffce5: Received PLOGI request kernel: host1: rport fffce5: Received PLOGI in INIT state kernel: host1: rport fffce5: Port is Ready kernel: host1: rport fffce5: Received PRLI request while in state Ready kernel: host1: rport fffce5: PRLI rspp type 8 active 1 passive 0 kernel: host1: rport fffce5: Received LOGO request while in state Ready kernel: host1: rport fffce5: Delete port kernel: host1: rport fffce5: Received PLOGI request kernel: host1: rport fffce5: Received PLOGI in state Delete - send busy Link: https://lore.kernel.org/r/20200622101212.3922-2-jhasan@marvell.com Reviewed-by: Girish Basrur <gbasrur@marvell.com> Reviewed-by: Saurav Kashyap <skashyap@marvell.com> Reviewed-by: Shyam Sundar <ssundar@marvell.com> Signed-off-by: Javed Hasan <jhasan@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-03-30scsi: libfc: rport state move to PLOGI if all PRLI retry exhaustedJaved Hasan1-0/+2
After all PRLI retries are exhausted, move rport state machine back to PLOGI state. Link: https://lore.kernel.org/r/20200327060208.17104-3-skashyap@marvell.com Signed-off-by: Javed Hasan <jhasan@marvell.com> Signed-off-by: Saurav Kashyap <skashyap@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2020-03-30scsi: libfc: If PRLI rejected, move rport to PLOGI stateJaved Hasan1-1/+7
If PRLI reject code indicates "rejected status", move rport state machine back to PLOGI state. Link: https://lore.kernel.org/r/20200327060208.17104-2-skashyap@marvell.com Signed-off-by: Javed Hasan <jhasan@marvell.com> Signed-off-by: Saurav Kashyap <skashyap@marvell.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-07-30scsi: fcoe: Embed fc_rport_priv in fcoe_rport structureHannes Reinecke1-1/+4
Gcc-9 complains for a memset across pointer boundaries, which happens as the code tries to allocate a flexible array on the stack. Turns out we cannot do this without relying on gcc-isms, so with this patch we'll embed the fc_rport_priv structure into fcoe_rport, can use the normal 'container_of' outcast, and will only have to do a memset over one structure. Signed-off-by: Hannes Reinecke <hare@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-06-05treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 335Thomas Gleixner1-13/+1
Based on 1 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms and conditions of the gnu general public license version 2 as published by the free software foundation this program is distributed in the hope it will be useful but without any warranty without even the implied warranty of merchantability or fitness for a particular purpose see the gnu general public license for more details you should have received a copy of the gnu general public license along with this program if not write to the free software foundation inc 51 franklin st fifth floor boston ma 02110 1301 usa extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 111 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Alexios Zavras <alexios.zavras@intel.com> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190530000436.567572064@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19Revert "scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO"Saurav Kashyap1-1/+0
This patch clears FC_RP_STARTED flag during logoff, because of this re-login(flogi) didn't happen to the switch. This reverts commit 1550ec458e0cf1a40a170ab1f4c46e3f52860f65. Fixes: 1550ec458e0c ("scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO") Cc: <stable@vger.kernel.org> # v4.18+ Signed-off-by: Saurav Kashyap <skashyap@marvell.com> Reviewed-by: Hannes Reinecke <hare@#suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2019-02-05Revert "scsi: libfc: Add WARN_ON() when deleting rports"Ross Lagerwall1-1/+0
This reverts commit bbc0f8bd88abefb0f27998f40a073634a3a2db89. It added a warning whose intent was to check whether the rport was still linked into the peer list. It doesn't work as intended and gives false positive warnings for two reasons: 1) If the rport is never linked into the peer list it will not be considered empty since the list_head is never initialized. 2) If the rport is deleted from the peer list using list_del_rcu(), then the list_head is in an undefined state and it is not considered empty. Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-29scsi: libfc: fc_rport: Mark expected switch fall-throughGustavo A. R. Silva1-0/+1
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-11-22scsi: libfc: Remove set but not used variable 'disc'Yue Haibing1-2/+0
Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/libfc/fc_rport.c: In function 'fc_rport_recv_flogi_req': drivers/scsi/libfc/fc_rport.c:866:18: warning: variable 'disc' set but not used [-Wunused-but-set-variable] It no used any more after commit baa6719f902a ("libfc: Update rport reference counting") Signed-off-by: Yue Haibing <yuehaibing@huawei.com> Reviewed-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-10-16scsi: libfc: retry PRLI if we cannot analyse the payloadHannes Reinecke1-2/+6
When we fail to analyse the payload of a PRLI response we should reset the state machine to retry the PRLI; eventually we will be getting a proper frame. Not doing so will result in a stuck state machine and the port never to be presented to the systsm. Suggested-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Arun Easi <arun.easi@cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-10-16scsi: libfc: check fc_frame_payload_get() return value for nullThomas Abraham1-4/+10
We should not assume the payload of a PRLI or PLOGI respons is always present. Signed-off-by: Thomas Abraham <tabraham@suse.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Arun Easi <arun.easi@cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-08-16Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsiLinus Torvalds1-55/+45
Pull SCSI updates from James Bottomley: "This is mostly updates to the usual drivers: mpt3sas, lpfc, qla2xxx, hisi_sas, smartpqi, megaraid_sas, arcmsr. In addition, with the continuing absence of Nic we have target updates for tcmu and target core (all with reviews and acks). The biggest observable change is going to be that we're (again) trying to switch to mulitqueue as the default (a user can still override the setting on the kernel command line). Other major core stuff is the removal of the remaining Microchannel drivers, an update of the internal timers and some reworks of completion and result handling" * tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi: (203 commits) scsi: core: use blk_mq_run_hw_queues in scsi_kick_queue scsi: ufs: remove unnecessary query(DM) UPIU trace scsi: qla2xxx: Fix issue reported by static checker for qla2x00_els_dcmd2_sp_done() scsi: aacraid: Spelling fix in comment scsi: mpt3sas: Fix calltrace observed while running IO & reset scsi: aic94xx: fix an error code in aic94xx_init() scsi: st: remove redundant pointer STbuffer scsi: qla2xxx: Update driver version to 10.00.00.08-k scsi: qla2xxx: Migrate NVME N2N handling into state machine scsi: qla2xxx: Save frame payload size from ICB scsi: qla2xxx: Fix stalled relogin scsi: qla2xxx: Fix race between switch cmd completion and timeout scsi: qla2xxx: Fix Management Server NPort handle reservation logic scsi: qla2xxx: Flush mailbox commands on chip reset scsi: qla2xxx: Fix unintended Logout scsi: qla2xxx: Fix session state stuck in Get Port DB scsi: qla2xxx: Fix redundant fc_rport registration scsi: qla2xxx: Silent erroneous message scsi: qla2xxx: Prevent sysfs access when chip is down scsi: qla2xxx: Add longer window for chip reset ...
2018-08-02scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGOJohannes Thumshirn1-0/+1
When receiving a LOGO request we forget to clear the FC_RP_STARTED flag before starting the rport delete routine. As the started flag was not cleared, we're not deleting the rport but waiting for a restart and thus are keeping the reference count of the rdata object at 1. This leads to the following kmemleak report: unreferenced object 0xffff88006542aa00 (size 512): comm "kworker/0:2", pid 24, jiffies 4294899222 (age 226.880s) hex dump (first 32 bytes): 68 96 fe 65 00 88 ff ff 00 00 00 00 00 00 00 00 h..e............ 01 00 00 00 08 00 00 00 02 c5 45 24 ac b8 00 10 ..........E$.... backtrace: [<(____ptrval____)>] fcoe_ctlr_vn_add.isra.5+0x7f/0x770 [libfcoe] [<(____ptrval____)>] fcoe_ctlr_vn_recv+0x12af/0x27f0 [libfcoe] [<(____ptrval____)>] fcoe_ctlr_recv_work+0xd01/0x32f0 [libfcoe] [<(____ptrval____)>] process_one_work+0x7ff/0x1420 [<(____ptrval____)>] worker_thread+0x87/0xef0 [<(____ptrval____)>] kthread+0x2db/0x390 [<(____ptrval____)>] ret_from_fork+0x35/0x40 [<(____ptrval____)>] 0xffffffffffffffff Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Reported-by: ard <ard@kwaak.net> Reviewed-by: Hannes Reinecke <hare@suse.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-07-13scsi: libfc: Add WARN_ON() when deleting rportsHannes Reinecke1-0/+1
The discovery rport list handling is quite odd; the list traversal is independent from the lifetime of the rport itself. This makes auditing quite tricky, and the chance remains that we've missed something. So this patch adds a WARN_ON() statement when freeing an rport which is still part of a list. Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-07-13scsi: libfc: fixup lockdep annotationsHannes Reinecke1-1/+1
fc_rport_recv_plogi_req() needs the lport mutex to be held; the rport mutex will be acquired in the function itself. Fixes: ee35624e1e4e ("scsi: libfc: Add lockdep annotations") Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2018-07-11scsi: libfc: Add lockdep annotationsHannes Reinecke1-55/+44
Convert the free text locking notes into proper lockdep annotations. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-10-06scsi: libfc: fix a deadlock in fc_rport_workSatish Kharat1-1/+1
In places like fc_rport_recv_plogi_req and fcoe_ctlr_vn_add we always take the lport disc_mutex lock before the rports mutex (rp_mutex) lock. Gaurding list_del_rcu(&rdata->peers) with disc.disc_mutex in fc_rport_work is correct but the rp_mutex lock can and should to be dropped before taking that lock else results in a deadlock. Signed-off-by: Satish Kharat <satishkh@cisco.com> Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-05-17scsi: libfc: fix incorrect variable assignmentGustavo A. R. Silva1-1/+1
Previous assignment was causing the use of the uninitialized variable _explan_ inside fc_seq_ls_rjt() function, which in this particular case is being called by fc_seq_els_rsp_send(). [mkp: fixed typo] Addresses-Coverity-ID: 1398125 Signed-off-by: Gustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by: Ewan D. Milne <emilne@redhat.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2017-03-02sched/headers: Prepare to use <linux/rcuupdate.h> instead of ↵Ingo Molnar1-0/+2
<linux/rculist.h> in <linux/sched.h> We don't actually need the full rculist.h header in sched.h anymore, we will be able to include the smaller rcupdate.h header instead. But first update code that relied on the implicit header inclusion. Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2016-11-25scsi: libfc: Remove an unneeded conditionDan Carpenter1-1/+0
We verified that resp_code is FC_SPP_RESP_ACK earlier so we don't need to check again here. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Remove fc_rport_init()Hannes Reinecke1-10/+0
Function is empty now and can be removed. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Reviewed-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->rport_flush_queue callback with function callHannes Reinecke1-4/+2
The ->rport_flush_queue callback only ever had a single implementation, so we can as well call it directly and drop the callback. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->rport_recv_req callback with function callHannes Reinecke1-4/+2
The ->rport_recv_req callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->rport_logoff callback with function callHannes Reinecke1-5/+3
The ->rport_logoff callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Reviewed-by: Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->rport_login callback with function callHannes Reinecke1-4/+10
The ->rport_login callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->rport_create callback with function callHannes Reinecke1-6/+3
The ->rport_create callback only ever had a single implementation, so we can as well call it directly and drop the callback. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->rport_lookup callback with function callHannes Reinecke1-9/+7
The ->rport_lookup callback only ever had a single implementation, so we can as well call it directly and drop the callback. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->rport_destroy callback with function callHannes Reinecke1-38/+30
The ->rport_destroy callback only ever had one implementation, so we can as well call it directly and drop the callback. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->exch_seq_send callback with function callHannes Reinecke1-2/+2
The ->exch_seq_send callback only ever had one implementation, so we can call the function directly and drop the callback. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Replace ->seq_els_rsp_send callback with function callHannes Reinecke1-13/+13
The 'seq_els_rsp_send' callback only ever had one implementation, so we might as well drop it and use the function directly. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Return LS_RJT_BUSY for PRLI in status PLOGIHannes Reinecke1-0/+17
Occasionally it might happen that we receive a PRLI while we're still waiting for our PLOGI response. In that case we should return 'busy' LS status instead of 'plogi required' LS status. Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Rework PRLI handlingHannes Reinecke1-18/+38
PRLI is only required if the port is acting as an initiator; ports which support target functionality only do not need to send PRLI. At the same time the PRLI state is only used if the port initiated a PRLI transfer; if we received a PRLI request we should _not_ change the state as this would cause our PRLI response to be dropped. And when we receive a PRLI response we need to check if an image pair has been established; if not the remote port cannot act as a target for us and we need to disable target functionality. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Implement RTV responderHannes Reinecke1-1/+40
The libfc stack generates an RTV request, so we should be implementing an RTV responder, too. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: use error code for fc_rport_error()Hannes Reinecke1-40/+61
We only ever use the 'fp' argument for fc_rport_error() to encapsulate the error code, so we can as well do away with that and pass the error directly. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: sanitize E_D_TOV and R_A_TOV settingHannes Reinecke1-2/+4
When setting the FCP timeout we need to ensure a lower boundary for E_D_TOV and R_A_TOV, otherwise we'd be getting spurious I/O issues due to the fcp timer firing too early. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: use configured rport E_D_TOVHannes Reinecke1-1/+1
If fc_rport_error_retry() is attempting to retry the remote port state we should be waiting for the configured e_d_tov value rather than the default. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: additional debugging messagesHannes Reinecke1-5/+20
Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: don't advance state machine for incoming FLOGIHannes Reinecke1-6/+14
When we receive an FLOGI but have already sent our own we should not advance the state machine but rather wait for our FLOGI to return before continuing with PLOGI. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Do not login if the port is already startedHannes Reinecke1-0/+6
When the port is already started we don't need to login; that will only confuse the state machine. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Do not drop down to FLOGI for fc_rport_login()Hannes Reinecke1-1/+5
When fc_rport_login() is called while the rport is not in RPORT_ST_INIT, RPORT_ST_READY, or RPORT_ST_DELETE login is already in progress and there's no need to drop down to FLOGI; doing so will only confuse the other side. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Do not take rdata->rp_mutex when processing a -FC_EX_CLOSED ELS ↵Chad Dupuis1-8/+24
response. When an ELS response handler receives a -FC_EX_CLOSED, the rdata->rp_mutex is already held which can lead to a deadlock condition like the following stack trace: [<ffffffffa04d8f18>] fc_rport_plogi_resp+0x28/0x200 [libfc] [<ffffffffa04cfa1a>] fc_invoke_resp+0x6a/0xe0 [libfc] [<ffffffffa04d0c08>] fc_exch_mgr_reset+0x1b8/0x280 [libfc] [<ffffffffa04d87b3>] fc_rport_logoff+0x43/0xd0 [libfc] [<ffffffffa04ce73d>] fc_disc_stop+0x6d/0xf0 [libfc] [<ffffffffa04ce7ce>] fc_disc_stop_final+0xe/0x20 [libfc] [<ffffffffa04d55f7>] fc_fabric_logoff+0x17/0x70 [libfc] The other ELS handlers need to follow the FLOGI response handler and simply do a kref_put against the fc_rport_priv struct and exit when receving a -FC_EX_CLOSED response. Signed-off-by: Chad Dupuis <chad.dupuis@cavium.com> Reviewed-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Fixup disc_mutex handlingHannes Reinecke1-0/+2
The list of attached 'rdata' remote port structures is RCU protected, so there is no need to take the 'disc_mutex' when traversing it. Rather we should be using rcu_read_lock() and kref_get_unless_zero() to validate the entries. We need, however, take the disc_mutex when deleting an entry; otherwise we risk clashes with list_add. Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-11-09scsi: libfc: Revisit kref handlingHannes Reinecke1-30/+101
The kref handling in fc_rport is a mess. This patch updates the kref handling according to the following rules: - Take a reference whenever scheduling a workqueue - Take a reference whenever an ELS command is send - Drop the reference at the end of the workqueue function - Drop the reference at the end of handling ELS replies - Take a reference when allocating an rport - Drop the reference when removing an rport Signed-off-by: Hannes Reinecke <hare@suse.com> Acked-by: Johannes Thumshirn <jth@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-08-19scsi: libfc: reset exchange manager during LOGO handlingHannes Reinecke1-1/+13
FC-LS mandates that we should invalidate all sequences before sending a LOGO. And we should set the event to RPORT_EV_STOP when a LOGO request has been received to signal that all exchanges are terminated. Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Chad Dupuis <chad.dupuis@qlogic.com> Tested-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
2016-08-19scsi: libfc: send LOGO for PLOGI failureHannes Reinecke1-1/+9
When running in point-to-multipoint mode PLOGI is done after FLOGI completed. So when the PLOGI fails we should be sending a LOGO to the remote port. [mkp: Applied by hand] Signed-off-by: Hannes Reinecke <hare@suse.com> Reviewed-by: Chad Dupuis <chad.dupuis@qlogic.com> Tested-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-01-12 10:11:47 +0300