From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Peter Oberparleiter <oberpar@linux.ibm.com>,
Vineeth Vijayan <vneethv@linux.ibm.com>,
Eric Farman <farman@linux.ibm.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Sasha Levin <sashal@kernel.org>,
hca@linux.ibm.com, agordeev@linux.ibm.com,
linux-s390@vger.kernel.org
Subject: [PATCH AUTOSEL 6.6 12/17] s390/cio: Fix CHPID "configure" attribute caching
Date: Tue, 18 Feb 2025 15:27:36 -0500 [thread overview]
Message-ID: <20250218202743.3593296-12-sashal@kernel.org> (raw)
In-Reply-To: <20250218202743.3593296-1-sashal@kernel.org>
From: Peter Oberparleiter <oberpar@linux.ibm.com>
[ Upstream commit 32ae4a2992529e2c7934e422035fad1d9b0f1fb5 ]
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>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/s390/cio/chp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/s390/cio/chp.c b/drivers/s390/cio/chp.c
index 5440f285f3494..7e00c061538db 100644
--- a/drivers/s390/cio/chp.c
+++ b/drivers/s390/cio/chp.c
@@ -661,7 +661,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);
--
2.39.5
parent reply other threads:[~2025-02-18 20:28 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20250218202743.3593296-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=20250218202743.3593296-12-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=agordeev@linux.ibm.com \
--cc=farman@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=oberpar@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=vneethv@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