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 6/8] zfcp: fence adapter status propagation for common statuses
Date: Fri, 8 May 2020 19:23:33 +0200 [thread overview]
Message-ID: <f51fe5f236a1e3d1ce53379c308777561bfe35e1.1588956679.git.bblock@linux.ibm.com> (raw)
In-Reply-To: <cover.1588956679.git.bblock@linux.ibm.com>
Common status flags that all main objects - adapter, port, and unit -
support are propagated to sub-objects when set or cleared. For instance,
when setting the status ZFCP_STATUS_COMMON_ERP_INUSE for an adapter
object, we will propagate this to all its child ports and units - same
for when clearing a common status flag.
Units of an adapter object are enumerated via __shost_for_each_device()
over the scsi host object of the corresponding adapter.
Once we move the scsi host object allocation and registration to after
the first exchange config and exchange port data, this won't be possible
for cases where we set or clear common statuses during the very first
adapter recovery.
But since we won't have any port or unit objects yet at that point of
time, we can just fence the status propagation for cases where the scsi
host object is not yet set in the adapter object. It won't change any
effective status propagations, but will prevent us from dereferencing
invalid pointers.
For any later point in the work flow the scsi host object will be set
and thus nothing is changed then.
Reviewed-by: Steffen Maier <maier@linux.ibm.com>
Signed-off-by: Benjamin Block <bblock@linux.ibm.com>
---
drivers/s390/scsi/zfcp_erp.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/s390/scsi/zfcp_erp.c b/drivers/s390/scsi/zfcp_erp.c
index 356f51d2bbee..283bcb985655 100644
--- a/drivers/s390/scsi/zfcp_erp.c
+++ b/drivers/s390/scsi/zfcp_erp.c
@@ -1642,6 +1642,13 @@ void zfcp_erp_set_adapter_status(struct zfcp_adapter *adapter, u32 mask)
atomic_or(common_mask, &port->status);
read_unlock_irqrestore(&adapter->port_list_lock, flags);
+ /*
+ * if `scsi_host` is missing, xconfig/xport data has never completed
+ * yet, so we can't access it, but there are also no SDEVs yet
+ */
+ if (adapter->scsi_host == NULL)
+ return;
+
spin_lock_irqsave(adapter->scsi_host->host_lock, flags);
__shost_for_each_device(sdev, adapter->scsi_host)
atomic_or(common_mask, &sdev_to_zfcp(sdev)->status);
@@ -1679,6 +1686,13 @@ void zfcp_erp_clear_adapter_status(struct zfcp_adapter *adapter, u32 mask)
}
read_unlock_irqrestore(&adapter->port_list_lock, flags);
+ /*
+ * if `scsi_host` is missing, xconfig/xport data has never completed
+ * yet, so we can't access it, but there are also no SDEVs yet
+ */
+ if (adapter->scsi_host == NULL)
+ return;
+
spin_lock_irqsave(adapter->scsi_host->host_lock, flags);
__shost_for_each_device(sdev, adapter->scsi_host) {
atomic_andnot(common_mask, &sdev_to_zfcp(sdev)->status);
--
2.17.1
next prev 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 ` Benjamin Block [this message]
2020-05-08 17:23 ` [PATCH 7/8] zfcp: fence early sysfs interfaces for accesses of shost objects Benjamin Block
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=f51fe5f236a1e3d1ce53379c308777561bfe35e1.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