diff mbox series

[v2,07/10] s390/dasd: Fix operational path inconsistency

Message ID 20201008131336.61100-8-sth@linux.ibm.com (mailing list archive)
State New, archived
Headers show
Series DASD FC endpoint security | expand

Commit Message

Stefan Haberland Oct. 8, 2020, 1:13 p.m. UTC
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(+)

Comments

Cornelia Huck Oct. 8, 2020, 2:37 p.m. UTC | #1
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>
diff mbox series

Patch

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);
 	}
 }