An error occurred fetching the project authors.
- 19 Apr, 2019 1 commit
-
-
Saurav Kashyap authored
This patch clears FC_RP_STARTED flag during logoff, because of this re-login(flogi) didn't happen to the switch. This reverts commit 1550ec45. Fixes: 1550ec45 ("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>
-
- 05 Feb, 2019 1 commit
-
-
Ross Lagerwall authored
This reverts commit bbc0f8bd. 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:
-
- 29 Nov, 2018 1 commit
-
-
Gustavo A. R. Silva authored
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:
-
- 22 Nov, 2018 1 commit
-
-
Yue Haibing authored
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 baa6719f ("libfc: Update rport reference counting") Signed-off-by:
Yue Haibing <yuehaibing@huawei.com> Reviewed-by:
-
- 16 Oct, 2018 2 commits
-
-
Hannes Reinecke authored
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:
Arun Easi <arun.easi@cavium.com> Signed-off-by:
-
Thomas Abraham authored
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:
-
- 02 Aug, 2018 1 commit
-
-
Johannes Thumshirn authored
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:
-
- 13 Jul, 2018 2 commits
-
-
Hannes Reinecke authored
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 authored
fc_rport_recv_plogi_req() needs the lport mutex to be held; the rport mutex will be acquired in the function itself. Fixes: ee35624e ("scsi: libfc: Add lockdep annotations") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 11 Jul, 2018 1 commit
-
-
Hannes Reinecke authored
Convert the free text locking notes into proper lockdep annotations. Signed-off-by:
-
- 06 Oct, 2017 1 commit
-
-
Satish Kharat authored
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:
-
- 17 May, 2017 1 commit
-
-
Gustavo A. R. Silva authored
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:
-
- 02 Mar, 2017 1 commit
-
-
Ingo Molnar authored
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>
-
- 25 Nov, 2016 1 commit
-
-
Dan Carpenter authored
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:
-
- 08 Nov, 2016 23 commits
-
-
Hannes Reinecke authored
Function is empty now and can be removed. Signed-off-by:
-
Hannes Reinecke authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
Bart Van Assche <bart.vanassche@sandisk.com> Signed-off-by:
-
Hannes Reinecke authored
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 authored
The libfc stack generates an RTV request, so we should be implementing an RTV responder, too. Signed-off-by:
-
Hannes Reinecke authored
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 authored
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 authored
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 authored
Signed-off-by:
-
Hannes Reinecke authored
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 authored
When the port is already started we don't need to login; that will only confuse the state machine. Signed-off-by:
-
Hannes Reinecke authored
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:
-
Chad Dupuis authored
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:
-
Hannes Reinecke authored
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 authored
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:
-
- 19 Aug, 2016 3 commits
-
-
Hannes Reinecke authored
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:
Chad Dupuis <chad.dupuis@qlogic.com> Tested-by:
-
Hannes Reinecke authored
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 authored
When receiving a PRLO it just means that the operating parameters have changed, it does _not_ mean that the port doesn't want to communicate with us. So instead of implicitly logging out we should be issueing a PRLI to figure out the new operating parameters. We can always recover once PRLI fails. Signed-off-by:
-
