Re: [PATCH v1 1/1] s390x: css: report errors from ccw_dstream_read/write

[Halil Pasic]

On Wed, 7 Apr 2021 13:41:57 +0200
Pierre Morel <pmorel@linux.ibm.com> wrote:

> > Here, however, I'm not sure. Returning a negative error here is fine,
> > but handle_payload_3270_write (not changed in this patch) seems to
> > match everything to -EIO. Shouldn't it just be propagated, and maybe 0
> > mapped to -EIO only? If I'm not confused, we'll end up mapping every
> > error to intervention required.  
> 
> I know very little about the 3270 but in my opinion accessing memory is 
> not the problem of the device but of the subchannel.
> So we should certainly propagate the error instead of returning -EIO for 
> any error.

I agree, what condition needs to be indicated when we encounter an
invalid CCW, IDAW or MIDAW address is clear. In the PoP this is
described under Chapter 16. I/O Interruptions > Subchannel-Status Word >
Subchannel-Status Field > Program Check in the paragraphs on "Invalid
IDAW or MIDAW Address and "Invalid CCW Address".

My guess about handle_payload_3270_write() is that IMHO the initial 3270
emulation code was, let's say of mixed quality in the first place, so
wouldn't seek some hidden meaning/sense, behind the -EIO. IMHO first
mapping architectural conditions to "errno-style" error codes, passing
these around, and then mapping them back is a litle non-intuitive. If one
looks at the purpose of handle_payload_3270_write(), it is basically
emulating an IO data transfer from the device into the main storage. If
that sort of operation. So with -EIO the original author probably wanted
to say: hey there was an input/output error, which ain't that wrong. The
problem is that somewhere up the call stack EIO gets interpreted in a
very peculiar way, and along with other errnos mapped to CIO
architecture stuff like SCSW bits.

Regards,
Halil