]> git.ipfire.org Git - thirdparty/kernel/linux.git/commitdiff
s390/cio: Fix CHPID "configure" attribute caching
authorPeter Oberparleiter <oberpar@linux.ibm.com>
Fri, 31 Jan 2025 11:02:55 +0000 (12:02 +0100)
committerVasily Gorbik <gor@linux.ibm.com>
Tue, 11 Feb 2025 18:35:08 +0000 (19:35 +0100)
In some environments, the SCLP firmware interface used to query a
CHPID's configured state is not supported. On these environments,
rapidly reading the corresponding sysfs attribute produces inconsistent
results:

  $ cat /sys/devices/css0/chp0.00/configure
  cat: /sys/devices/css0/chp0.00/configure: Operation not supported
  $ cat /sys/devices/css0/chp0.00/configure
  3

This occurs for example when Linux is run as a KVM guest. The
inconsistency is a result of CIO using cached results for generating
the value of the "configure" attribute while failing to handle the
situation where no data was returned by SCLP.

Fix this by not updating the cache-expiration timestamp when SCLP
returns no data. With the fix applied, the system response is
consistent:

  $ cat /sys/devices/css0/chp0.00/configure
  cat: /sys/devices/css0/chp0.00/configure: Operation not supported
  $ cat /sys/devices/css0/chp0.00/configure
  cat: /sys/devices/css0/chp0.00/configure: Operation not supported

Reviewed-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Eric Farman <farman@linux.ibm.com>
Tested-by: Eric Farman <farman@linux.ibm.com>
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
drivers/s390/cio/chp.c

index 4a0b3f19bd8ef9780da6b4657fbda73171e8c22b..4f01b1929240eb1f31f3b51875b18c8343548df8 100644 (file)
@@ -695,7 +695,8 @@ static int info_update(void)
        if (time_after(jiffies, chp_info_expires)) {
                /* Data is too old, update. */
                rc = sclp_chp_read_info(&chp_info);
-               chp_info_expires = jiffies + CHP_INFO_UPDATE_INTERVAL ;
+               if (!rc)
+                       chp_info_expires = jiffies + CHP_INFO_UPDATE_INTERVAL;
        }
        mutex_unlock(&info_lock);