From: Stefan Haberland <sth@linux.ibm.com>
To: axboe@kernel.dk
Cc: linux-block@vger.kernel.org, hoeppner@linux.ibm.com,
linux-s390@vger.kernel.org, heiko.carstens@de.ibm.com,
gor@linux.ibm.com, borntraeger@de.ibm.com
Subject: [PATCH 07/10] s390/dasd: Fix operational path inconsistency
Date: Fri, 2 Oct 2020 21:39:37 +0200 [thread overview]
Message-ID: <20201002193940.24012-8-sth@linux.ibm.com> (raw)
In-Reply-To: <20201002193940.24012-1-sth@linux.ibm.com>
From: Jan Höppner <hoeppner@linux.ibm.com>
During online processing and setting up a DASD device, the configuration
data for operational paths is read and validated two times
(dasd_eckd_read_conf()). The first time to provide information that are
necessary for the LCU setup. A second time after the LCU setup as a
device might report different configuration data then.
When the configuration setup for each operational path is being
validated, an initial call to dasd_eckd_clear_conf_data() is issued.
This call wipes all previously available configuration data and path
information for each path.
However, the operational path mask is not updated during this process.
As a result, the stored operational path mask might no longer correspond
to the operational paths mask reported by the CIO layer, as several
paths might be gone between the two dasd_eckd_read_conf() calls.
This inconsistency leads to more severe issues in later path handling
changes. Fix this by removing the channel paths from the operational
path mask during the dasd_eckd_clear_conf_data() call.
Reference-ID: IO1812
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
---
drivers/s390/block/dasd_eckd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/s390/block/dasd_eckd.c b/drivers/s390/block/dasd_eckd.c
index 274f79869b7c..271768e4606c 100644
--- a/drivers/s390/block/dasd_eckd.c
+++ b/drivers/s390/block/dasd_eckd.c
@@ -1029,6 +1029,7 @@ static void dasd_eckd_clear_conf_data(struct dasd_device *device)
device->path[i].cssid = 0;
device->path[i].ssid = 0;
device->path[i].chpid = 0;
+ dasd_path_notoper(device, i);
}
}
--
2.17.1
next prev parent reply other threads:[~2020-10-02 19:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-02 19:39 [PATCH 00/10] DASD FC endpoint security Stefan Haberland
2020-10-02 19:39 ` [PATCH 01/10] s390/cio: Export information about Endpoint-Security Capability Stefan Haberland
2020-10-06 9:46 ` Cornelia Huck
2020-10-06 14:23 ` Stefan Haberland
2020-10-06 14:37 ` Cornelia Huck
2020-10-02 19:39 ` [PATCH 02/10] s390/cio: Provide Endpoint-Security Mode per CU Stefan Haberland
2020-10-06 14:46 ` Cornelia Huck
2020-10-07 14:24 ` Stefan Haberland
2020-10-07 16:13 ` Cornelia Huck
2020-10-02 19:39 ` [PATCH 03/10] s390/cio: Add support for FCES status notification Stefan Haberland
2020-10-02 19:39 ` [PATCH 04/10] s390/dasd: Remove unused parameter from dasd_generic_probe() Stefan Haberland
2020-10-02 19:39 ` [PATCH 05/10] s390/dasd: Move duplicate code to separate function Stefan Haberland
2020-10-02 19:39 ` [PATCH 06/10] s390/dasd: Store path configuration data during path handling Stefan Haberland
2020-10-02 19:39 ` Stefan Haberland [this message]
2020-10-02 19:39 ` [PATCH 08/10] s390/dasd: Display FC Endpoint Security information via sysfs Stefan Haberland
2020-10-06 10:26 ` Cornelia Huck
2020-10-06 16:57 ` Jan Höppner
2020-10-07 9:49 ` Cornelia Huck
2020-10-07 14:33 ` Jan Höppner
2020-10-07 16:40 ` Cornelia Huck
2020-10-07 20:10 ` Jan Höppner
2020-10-08 7:03 ` Cornelia Huck
2020-10-08 11:04 ` Stefan Haberland
2020-10-02 19:39 ` [PATCH 09/10] s390/dasd: Prepare for additional path event handling Stefan Haberland
2020-10-02 19:39 ` [PATCH 10/10] s390/dasd: Process FCES path event notification Stefan Haberland
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=20201002193940.24012-8-sth@linux.ibm.com \
--to=sth@linux.ibm.com \
--cc=axboe@kernel.dk \
--cc=borntraeger@de.ibm.com \
--cc=gor@linux.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=hoeppner@linux.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.