zfcp: cleanups and small changes for 5.9

---
 drivers/s390/scsi/zfcp_fc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/s390/scsi/zfcp_fc.c +1 -1

index b018b61bd168..d24cafe02708 100644
@@ -48,7 +48,7 @@ unsigned int zfcp_fc_port_scan_backoff(void)
 {
 	if (!port_scan_backoff)
 		return 0;
-	return get_random_int() % port_scan_backoff;
+	return prandom_u32_max(port_scan_backoff);
 }
 
 static void zfcp_fc_port_scan_time(struct zfcp_adapter *adapter)

Signature · 1 line

2.26.2

Benjamin Block

author

2020-07-03 13:21 UTC #2 lore raw

PATCH 2/7 zfcp: fix an outdated comment for zfcp_qdio_send()

From: Julian Wiedmann <[email protected]>

zfcp no longer uses the qdio PCI flag, update the comment.

Fixes 21ddaa53f92d ("[SCSI] zfcp: Remove PCI flag")

Reviewed-by Fedor Loshakov <[email protected]>

---
 drivers/s390/scsi/zfcp_qdio.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/s390/scsi/zfcp_qdio.c +1 -1

index 3a7f3374d10a..d3d110a04884 100644
@@ -246,7 +246,7 @@ int zfcp_qdio_sbal_get(struct zfcp_qdio *qdio)
 }
 
 /**
- * zfcp_qdio_send - set PCI flag in first SBALE and send req to QDIO
+ * zfcp_qdio_send - send req to QDIO
  * @qdio: pointer to struct zfcp_qdio
  * @q_req: pointer to struct zfcp_qdio_req
  * Returns: 0 on success, error otherwise

Signature · 1 line

2.26.2

Benjamin Block

author

2020-07-03 13:21 UTC #3 lore raw

PATCH 3/7 scsi: docs: update outdated link to IBM developerworks

IBM decided to retire a lot of the content that was previously hosted on "developerworks", and so some of the links we've used for documentation are now dead or redirect to some general landing page with no correlation to what the links were meant to provide.

The s390-tools package is meanwhile also hosted on github, so we can link to the script directly instead of to the archive.

Reviewed-by Julian Wiedmann <[email protected]>

---
 Documentation/scsi/scsi-parameters.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Documentation/scsi/scsi-parameters.rst +1 -1

index 9aba897c97ac..e5f68b431f5c 100644
@@ -94,7 +94,7 @@ parameters may be changed at runtime by the command
 			(/proc/sys/dev/scsi/logging_level).
 			There is also a nice 'scsi_logging_level' script in the
 			S390-tools package, available for download at
-			http://www-128.ibm.com/developerworks/linux/linux390/s390-tools-1.5.4.html
+			https://github.com/ibm-s390-tools/s390-tools/blob/master/scripts/scsi_logging_level
 
 	scsi_mod.scan=	[SCSI] sync (default) scans SCSI busses as they are
 			discovered.  async scans them in kernel threads,

Signature · 1 line

2.26.2

Benjamin Block

author

2020-07-03 13:21 UTC #4 lore raw

PATCH 4/7 scsi: docs: remove invalid link and update text for zfcp kernel config

Change the provided link in the Kconfig file for zfcp to rather refer to our device drivers book that we regularly update and publish for free, and whose name hasn't been changed since it was first published.

Our hardware is also not called "IBM eServer zSeries" anymore - in fact, it hasn't been called like that since 2006. Use a broader term that covers different server names over time.

Lastly, add a short paragraph about how our HBAs are typically named, to have some more tangible references.

Reviewed-by Julian Wiedmann <[email protected]>

---
 drivers/scsi/Kconfig | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)

drivers/scsi/Kconfig +10 -5

index e9ff4cd5fbe9..571473a58f98 100644
@@ -1469,14 +1469,19 @@ config SCSI_SUNESP
 	  module will be called sun_esp.
 
 config ZFCP
-	tristate "FCP host bus adapter driver for IBM eServer zSeries"
+	tristate "FCP host bus adapter driver for IBM mainframes"
 	depends on S390 && QDIO && SCSI
 	depends on SCSI_FC_ATTRS
 	help
-          If you want to access SCSI devices attached to your IBM eServer
-          zSeries by means of Fibre Channel interfaces say Y.
-          For details please refer to the documentation provided by IBM at
-          <http://oss.software.ibm.com/developerworks/opensource/linux390>
+	  If you want to access SCSI devices attached to your IBM mainframe by
+	  means of Fibre Channel Protocol host bus adapters say Y.
+
+	  Supported HBAs include different models of the FICON Express and FCP
+	  Express I/O cards.
+
+	  For a more complete list, and for more details about setup and
+	  operation refer to the IBM publication "Device Drivers, Features, and
+	  Commands", SC33-8411.
 
           This driver is also available as a module. This module will be
           called zfcp. If you want to compile it as a module, say M here

Signature · 1 line

2.26.2

Benjamin Block

author

2020-07-03 13:21 UTC #5 lore raw

PATCH 5/7 zfcp: clean up zfcp_erp_action_ready()

From: Julian Wiedmann <[email protected]>

We already maintain a pointer to act->adapter. Use it consistently to avoid any confusion about whose ->erp_ready_head and ->erp_ready_wq we are accessing.

---
 drivers/s390/scsi/zfcp_erp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

drivers/s390/scsi/zfcp_erp.c +1 -1

index 79f6e8fb03ca..59e662df5774 100644
@@ -68,7 +68,7 @@ static void zfcp_erp_action_ready(struct zfcp_erp_action *act)
 {
 	struct zfcp_adapter *adapter = act->adapter;
 
-	list_move(&act->list, &act->adapter->erp_ready_head);
+	list_move(&act->list, &adapter->erp_ready_head);
 	zfcp_dbf_rec_run("erardy1", act);
 	wake_up(&adapter->erp_ready_wq);
 	zfcp_dbf_rec_run("erardy2", act);

Signature · 1 line

2.26.2

Benjamin Block

author

2020-07-03 13:21 UTC #6 lore raw

PATCH 6/7 zfcp: replace open-coded list move

From: Julian Wiedmann <[email protected]>

Instead of manually moving each element of the unit and port lists into our temporary on-stack lists, splice them over in one go.

---
 drivers/s390/scsi/zfcp_ccw.c | 7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

drivers/s390/scsi/zfcp_ccw.c +3 -4

index 49eda141ea43..d9fd0a41da64 100644
@@ -124,13 +124,12 @@ static void zfcp_ccw_remove(struct ccw_device *cdev)
 		return;
 
 	write_lock_irq(&adapter->port_list_lock);
-	list_for_each_entry_safe(port, p, &adapter->port_list, list) {
+	list_for_each_entry(port, &adapter->port_list, list) {
 		write_lock(&port->unit_list_lock);
-		list_for_each_entry_safe(unit, u, &port->unit_list, list)
-			list_move(&unit->list, &unit_remove_lh);
+		list_splice_init(&port->unit_list, &unit_remove_lh);
 		write_unlock(&port->unit_list_lock);
-		list_move(&port->list, &port_remove_lh);
 	}
+	list_splice_init(&adapter->port_list, &port_remove_lh);
 	write_unlock_irq(&adapter->port_list_lock);
 	zfcp_ccw_adapter_put(adapter); /* put from zfcp_ccw_adapter_by_cdev */

Signature · 1 line

2.26.2

Benjamin Block

author

2020-07-03 13:21 UTC #7 lore raw

PATCH 7/7 zfcp: avoid benign overflow of the Request Queue's free-level

From: Julian Wiedmann <[email protected]>

zfcp_qdio_send() and zfcp_qdio_int_req() run concurrently, adding and completing SBALs on the Request Queue. There's a theoretical race where zfcp_qdio_int_req() completes a number of SBALs & increments the queue's free-level _before_ zfcp_qdio_send() was able to decrement it.

This can cause ->req_q_free to momentarily hold a value larger than QDIO_MAX_BUFFERS_PER_Q. Luckily zfcp_qdio_send() is always called under ->req_q_lock, and all readers of the free-level also take this lock. So we can trust that zfcp_qdio_send() will clean up such a temporary overflow before anyone can actually observe it.

But it's still confusing and annoying to worry about. So adjust the code to avoid this race.

---
 drivers/s390/scsi/zfcp_qdio.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

drivers/s390/scsi/zfcp_qdio.c +4 -1

index d3d110a04884..e78d65bd46b1 100644
@@ -260,17 +260,20 @@ int zfcp_qdio_send(struct zfcp_qdio *qdio, struct zfcp_qdio_req *q_req)
 	zfcp_qdio_account(qdio);
 	spin_unlock(&qdio->stat_lock);
 
+	atomic_sub(sbal_number, &qdio->req_q_free);
+
 	retval = do_QDIO(qdio->adapter->ccw_device, QDIO_FLAG_SYNC_OUTPUT, 0,
 			 q_req->sbal_first, sbal_number);
 
 	if (unlikely(retval)) {
+		/* Failed to submit the IO, roll back our modifications. */
+		atomic_add(sbal_number, &qdio->req_q_free);
 		zfcp_qdio_zero_sbals(qdio->req_q, q_req->sbal_first,
 				     sbal_number);
 		return retval;
 	}
 
 	/* account for transferred buffers */
-	atomic_sub(sbal_number, &qdio->req_q_free);
 	qdio->req_q_idx += sbal_number;
 	qdio->req_q_idx %= QDIO_MAX_BUFFERS_PER_Q;

Signature · 1 line

2.26.2

Martin K. Petersen

Applied

2020-07-08 06:09 UTC #8 lore raw