kernel/linux.git/drivers/scsi/libfc, branch linux-4.20.y

Revert "scsi: libfc: Add WARN_ON() when deleting rports"

2019-03-13T21:04:16+00:00

[ Upstream commit d8f6382a7d026989029e2e50c515df954488459b ] 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 Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: libfc: free skb when receiving invalid flogi resp

2019-03-13T21:04:06+00:00

[ Upstream commit 5d8fc4a9f0eec20b6c07895022a6bea3fb6dfb38 ] The issue to be fixed in this commit is when libfc found it received a invalid FLOGI response from FC switch, it would return without freeing the fc frame, which is just the skb data. This would cause memory leak if FC switch keeps sending invalid FLOGI responses. This fix is just to make it execute `fc_frame_free(fp)` before returning from function `fc_lport_flogi_resp`. Signed-off-by: Ming Lu Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin

scsi: libfc: retry PRLI if we cannot analyse the payload

2018-10-16T03:53:37+00:00

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 Signed-off-by: Hannes Reinecke Reviewed-by: Arun Easi Signed-off-by: Martin K. Petersen

scsi: libfc: check fc_frame_payload_get() return value for null

2018-10-16T03:53:36+00:00

We should not assume the payload of a PRLI or PLOGI respons is always present. Signed-off-by: Thomas Abraham Reviewed-by: Hannes Reinecke Reviewed-by: Arun Easi Signed-off-by: Martin K. Petersen

scsi: libfc: remove set but not used variable 'rpriv'

2018-09-12T00:59:11+00:00

Fixes gcc '-Wunused-but-set-variable' warning: drivers/scsi/libfc/fc_fcp.c: In function 'fc_queuecommand': drivers/scsi/libfc/fc_fcp.c:1875:30: warning: variable 'rpriv' set but not used [-Wunused-but-set-variable] Signed-off-by: YueHaibing Acked-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen

scsi: libfc: remove unnecessary condition check

2018-08-30T11:36:48+00:00

kmem_cache_destroy() can handle NULL pointer correctly, so there is no need to check NULL pointer before calling kmem_cache_destroy() Signed-off-by: Chengguang Xu Acked-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen

Merge tag 'scsi-misc' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi

2018-08-16T05:06:26+00:00

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 ...

scsi: fcoe: clear FC_RP_STARTED flags when receiving a LOGO

2018-08-02T19:30:03+00:00

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 Reported-by: ard Reviewed-by: Hannes Reinecke Signed-off-by: Martin K. Petersen

scsi: libfc: Add WARN_ON() when deleting rports

2018-07-13T03:01:16+00:00

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 Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen

scsi: libfc: hold disc_mutex in fc_disc_stop_rports()

2018-07-13T03:01:16+00:00

fc_disc_stop_rports() is calling fc_rport_logoff(), which in turn is acquiring the rport mutex. So we cannot use RCU list traversal here, but rather need to hold the disc mutex to avoid list corruption while traversing. Fixes: a407c593398c ("scsi: libfc: Fixup disc_mutex handling") Signed-off-by: Hannes Reinecke Reviewed-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen