From: Cornelia Huck <cohuck@redhat.com>
To: Stefan Haberland <sth@linux.ibm.com>
Cc: Jens Axboe <axboe@kernel.dk>,
linux-block@vger.kernel.org,
Jan Hoeppner <hoeppner@linux.ibm.com>,
linux-s390@vger.kernel.org,
Heiko Carstens <heiko.carstens@de.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Christian Borntraeger <borntraeger@de.ibm.com>
Subject: Re: [PATCH v2 07/10] s390/dasd: Fix operational path inconsistency
Date: Thu, 8 Oct 2020 16:37:56 +0200 [thread overview]
Message-ID: <20201008163756.3d1443b9.cohuck@redhat.com> (raw)
In-Reply-To: <20201008131336.61100-8-sth@linux.ibm.com>
On Thu, 8 Oct 2020 15:13:33 +0200
Stefan Haberland <sth@linux.ibm.com> wrote:
> 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.
>
> 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 3ff7b532a5bf..3273b26b25b0 100644
> --- a/drivers/s390/block/dasd_eckd.c
> +++ b/drivers/s390/block/dasd_eckd.c
> @@ -1034,6 +1034,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);
> }
> }
>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
next prev parent reply other threads:[~2020-10-08 14:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-08 13:13 [PATCH v2 00/10] DASD FC endpoint security Stefan Haberland
2020-10-08 13:13 ` [PATCH v2 01/10] s390/cio: Export information about Endpoint-Security Capability Stefan Haberland
2020-10-08 13:13 ` [PATCH v2 02/10] s390/cio: Provide Endpoint-Security Mode per CU Stefan Haberland
2020-10-08 13:13 ` [PATCH v2 03/10] s390/cio: Add support for FCES status notification Stefan Haberland
2020-10-08 13:13 ` [PATCH v2 04/10] s390/dasd: Remove unused parameter from dasd_generic_probe() Stefan Haberland
2020-10-08 14:13 ` Cornelia Huck
2020-10-08 13:13 ` [PATCH v2 05/10] s390/dasd: Move duplicate code to separate function Stefan Haberland
2020-10-08 14:16 ` Cornelia Huck
2020-10-08 13:13 ` [PATCH v2 06/10] s390/dasd: Store path configuration data during path handling Stefan Haberland
2020-10-08 14:21 ` Cornelia Huck
2020-10-08 13:13 ` [PATCH v2 07/10] s390/dasd: Fix operational path inconsistency Stefan Haberland
2020-10-08 14:37 ` Cornelia Huck [this message]
2020-10-08 13:13 ` [PATCH v2 08/10] s390/dasd: Display FC Endpoint Security information via sysfs Stefan Haberland
2020-10-08 14:43 ` Cornelia Huck
2020-10-08 13:13 ` [PATCH v2 09/10] s390/dasd: Prepare for additional path event handling Stefan Haberland
2020-10-08 14:48 ` Cornelia Huck
2020-10-08 13:13 ` [PATCH v2 10/10] s390/dasd: Process FCES path event notification Stefan Haberland
2020-10-08 14:54 ` Cornelia Huck
2020-10-08 14:56 ` Jan Höppner
2020-10-12 19:06 ` [PATCH v2 00/10] DASD FC endpoint security Stefan Haberland
2020-10-12 19:33 ` Jens Axboe
2020-10-12 19:50 ` Stefan Haberland
2020-10-13 19:40 ` Jens Axboe
2020-10-13 20:15 ` Stefan Haberland
2020-10-14 1:19 ` Jens Axboe
2020-11-10 15:50 ` Stefan Haberland
2020-11-11 16:20 ` Jens Axboe
2020-11-12 13:27 ` 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=20201008163756.3d1443b9.cohuck@redhat.com \
--to=cohuck@redhat.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 \
--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 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.