From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: "Jan Höppner" <hoeppner@linux.ibm.com>,
"Stefan Haberland" <sth@linux.ibm.com>,
"Cornelia Huck" <cohuck@redhat.com>,
"Jens Axboe" <axboe@kernel.dk>, "Sasha Levin" <sashal@kernel.org>,
linux-s390@vger.kernel.org
Subject: [PATCH AUTOSEL 4.19 29/87] s390/dasd: Fix operational path inconsistency
Date: Tue, 22 Dec 2020 21:20:05 -0500 [thread overview]
Message-ID: <20201223022103.2792705-29-sashal@kernel.org> (raw)
In-Reply-To: <20201223022103.2792705-1-sashal@kernel.org>
From: Jan Höppner <hoeppner@linux.ibm.com>
[ Upstream commit 9e34c8ba91697cb7441805c36d92ab3e695df6e0 ]
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.
Signed-off-by: Jan Höppner <hoeppner@linux.ibm.com>
Signed-off-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Stefan Haberland <sth@linux.ibm.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
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 a2e34c853ca98..a801ee11843c3 100644
--- a/drivers/s390/block/dasd_eckd.c
+++ b/drivers/s390/block/dasd_eckd.c
@@ -981,6 +981,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.27.0
parent reply other threads:[~2020-12-23 2:20 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20201223022103.2792705-1-sashal@kernel.org>]
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=20201223022103.2792705-29-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=axboe@kernel.dk \
--cc=cohuck@redhat.com \
--cc=hoeppner@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=sth@linux.ibm.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