Re: [PATCH 0/3] s390/cio: Harden pmcw/schib handling for dnv=0

[Vineeth Vijayan <vneethv@linux.ibm.com>]

On 9/14/26 14:17, Heiko Carstens wrote:
> On Thu, Sep 10, 2026 at 11:32:00AM +0200, Vineeth Vijayan wrote:
>> For I/O subchannels, pmcw.dnv must be validated before relying on any
>> other PMCW or SCHIB fields.
>> Two issues exist today:
>>   - Some I/O entry points check pmcw.ena without first verifying that
>>     pmcw.dnv is set.
>>   - cio_update_schib() updates the cached SCHIB before validating
>>     pmcw.dnv, allowing an stsch result with dnv=0 to leave stale or
>>     undefined data in sch->schib.
>>   
>> This can trigger spurious, non-fatal error messages in the guest kernel
>> log when a virtio device is being detached.
>>   
>> Fix this by validating pmcw.dnv before updating the cached SCHIB. Also
>> clear the cached SCHIB when stsch succeeds but returns dnv=0, ensuring
>> that stale state is not retained.
>>   
>> Additionally, add pmcw.dnv checks before pmcw.ena checks in I/O entry
>> points and return -ENODEV when no device is present. Guard remaining
>> direct accesses to cached PMCW fields, such as chpid[] and pam, to
>> ensure they are only evaluated when the SCHIB contents are valid.
>>   
>> This was reported and discussed at:
>>   
>> Link: https://lore.kernel.org/linux-s390/20260612155407.199218-1-wbezenah@linux.ibm.com/
>>
>> Vineeth Vijayan (3):
>>    s390/cio: Fix cio_update_schib() to not cache invalid schib
>>    s390/cio: Check pmcw.dnv before pmcw.ena in I/O entry points
>>    s390/cio: Guard PMCW field accesses with dnv check
>>
>>   drivers/s390/cio/chp.c          |  3 +++
>>   drivers/s390/cio/cio.c          | 11 +++++++----
>>   drivers/s390/cio/device.c       |  9 +++++----
>>   drivers/s390/cio/device_fsm.c   |  3 +++
>>   drivers/s390/cio/device_ops.c   | 21 +++++++++++++++++++++
>>   drivers/s390/cio/vfio_ccw_fsm.c |  2 +-
>>   6 files changed, 40 insertions(+), 9 deletions(-)
> 
> What is supposed to happen with this series? Since none of the s390
> maintainers were on to/cc I assume this is not supposed to go upstream
> and can be ignored?

Hi Heiko,

My bad. I missed adding the maintainers explicitly.
I was expecting to get the review comments from the reporter and
from Sashiko.

Looks like There are no major issues introduced by this patch. So,
could you please not ignore and consider the series for
upstreaming.