public inbox for linux-s390@vger.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Block <bblock@linux.ibm.com>
To: "James E.J. Bottomley" <jejb@linux.ibm.com>,
	"Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Benjamin Block <bblock@linux.ibm.com>,
	Steffen Maier <maier@linux.ibm.com>,
	Heiko Carstens <heiko.carstens@de.ibm.com>,
	Vasily Gorbik <gor@linux.ibm.com>,
	Christian Borntraeger <borntraeger@de.ibm.com>,
	Fedor Loshakov <loshakov@linux.ibm.com>,
	Julian Wiedmann <jwi@linux.ibm.com>,
	linux-scsi@vger.kernel.org, linux-s390@vger.kernel.org
Subject: [PATCH 7/8] zfcp: fence early sysfs interfaces for accesses of shost objects
Date: Fri,  8 May 2020 19:23:34 +0200	[thread overview]
Message-ID: <ef65366d309993ca91b6917727590ca7ca166c8f.1588956679.git.bblock@linux.ibm.com> (raw)
In-Reply-To: <cover.1588956679.git.bblock@linux.ibm.com>

When setting an adapter online for the first time, we also create a
couple of entries for it in the sysfs device tree. This is also true
even if the adapter has not yet ever gone successfully through exchange
config and exchange port data.

When moving the scsi host object allocation and registration to after
the first exchange config and exchange port data, this make
the `port_rescan` attribute susceptible to invalid pointer-dereferences
of the shost field before the adapter is fully initialized.

When written to, it schedules a `scan_work` item that will in turn make
use of the associated fibre channel host object to check the topology
used for this FCP device.

Because scanning for remote ports can't be done successfully without
completing exchange config and exchange port data first, we can simply
fence `port_rescan`, and so prevent the illegal access.

As with cases where we can't get a reference to the adapter, we also
return -ENODEV here. Applications need to handle that errno today
already.

After a successful allocation of the scsi host object nothing changes in
the work flow.

Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
---
 drivers/s390/scsi/zfcp_sysfs.c | 16 ++++++++++++++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/s390/scsi/zfcp_sysfs.c b/drivers/s390/scsi/zfcp_sysfs.c
index 7ec30ded0169..8d9662e8b717 100644
--- a/drivers/s390/scsi/zfcp_sysfs.c
+++ b/drivers/s390/scsi/zfcp_sysfs.c
@@ -216,10 +216,22 @@ static ssize_t zfcp_sysfs_port_rescan_store(struct device *dev,
 {
 	struct ccw_device *cdev = to_ccwdev(dev);
 	struct zfcp_adapter *adapter = zfcp_ccw_adapter_by_cdev(cdev);
+	int retval = 0;
 
 	if (!adapter)
 		return -ENODEV;
 
+	/*
+	 * If `scsi_host` is missing, we can't schedule `scan_work`, as it
+	 * makes use of the corresponding fc_host object. But this state is
+	 * only possible if xconfig/xport data has never completed yet,
+	 * and we couldn't successfully scan for ports anyway.
+	 */
+	if (adapter->scsi_host == NULL) {
+		retval = -ENODEV;
+		goto out;
+	}
+
 	/*
 	 * Users wish is our command: immediately schedule and flush a
 	 * worker to conduct a synchronous port scan, that is, neither
@@ -227,9 +239,9 @@ static ssize_t zfcp_sysfs_port_rescan_store(struct device *dev,
 	 */
 	queue_delayed_work(adapter->work_queue, &adapter->scan_work, 0);
 	flush_delayed_work(&adapter->scan_work);
+out:
 	zfcp_ccw_adapter_put(adapter);
-
-	return (ssize_t) count;
+	return retval ? retval : (ssize_t) count;
 }
 static ZFCP_DEV_ATTR(adapter, port_rescan, S_IWUSR, NULL,
 		     zfcp_sysfs_port_rescan_store);
-- 
2.17.1

  parent reply	other threads:[~2020-05-08 17:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 17:23 [PATCH 0/8] zfcp: fix DIF/DIX support with scsi-mq host-wide tag-set Benjamin Block
2020-05-08 17:23 ` [PATCH 1/8] zfcp: move shost modification after QDIO (re-)open into fenced function Benjamin Block
2020-05-08 17:23 ` [PATCH 2/8] zfcp: move shost updates during xconfig data handling " Benjamin Block
2020-05-08 17:23 ` [PATCH 3/8] zfcp: move fc_host updates during xport " Benjamin Block
2020-05-08 17:23 ` [PATCH 4/8] zfcp: fence fc_host updates during link-down handling Benjamin Block
2020-05-08 17:23 ` [PATCH 5/8] zfcp: move p-t-p port allocation to after xport data Benjamin Block
2020-05-08 17:23 ` [PATCH 6/8] zfcp: fence adapter status propagation for common statuses Benjamin Block
2020-05-08 17:23 ` Benjamin Block [this message]
2020-05-08 17:23 ` [PATCH 8/8] zfcp: move allocation of the shost object to after xconf- and xport-data Benjamin Block
2020-05-12  3:28 ` [PATCH 0/8] zfcp: fix DIF/DIX support with scsi-mq host-wide tag-set Martin K. Petersen
2020-05-12  9:27   ` Benjamin Block

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ef65366d309993ca91b6917727590ca7ca166c8f.1588956679.git.bblock@linux.ibm.com \
    --to=bblock@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jejb@linux.ibm.com \
    --cc=jwi@linux.ibm.com \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=loshakov@linux.ibm.com \
    --cc=maier@linux.ibm.com \
    --cc=martin.petersen@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox