From: Cornelia Huck <cohuck@redhat.com>
To: Pierre Morel <pmorel@linux.ibm.com>
Cc: thuth@redhat.com, frankja@linux.ibm.com, david@redhat.com,
mst@redhat.com, richard.henderson@linaro.org,
qemu-devel@nongnu.org, Halil Pasic <pasic@linux.ibm.com>,
borntraeger@de.ibm.com, qemu-s390x@nongnu.org,
marcandre.lureau@redhat.com, pbonzini@redhat.com,
imbrenda@linux.ibm.com
Subject: Re: [PATCH v2 1/1] s390x: css: report errors from ccw_dstream_read/write
Date: Fri, 9 Apr 2021 12:11:02 +0200 [thread overview]
Message-ID: <20210409121102.2e7da357.cohuck@redhat.com> (raw)
In-Reply-To: <7fe88dbf-7d0e-41bd-94f7-0f14bdae92b9@linux.ibm.com>
On Fri, 9 Apr 2021 11:55:56 +0200
Pierre Morel <pmorel@linux.ibm.com> wrote:
> On 4/9/21 10:49 AM, Cornelia Huck wrote:
> > On Fri, 9 Apr 2021 10:38:37 +0200
> > Halil Pasic <pasic@linux.ibm.com> wrote:
> >
> >> On Thu, 8 Apr 2021 18:32:09 +0200
> >> Pierre Morel <pmorel@linux.ibm.com> wrote:
> >>
> >>> ccw_dstream_read/write functions returned values are sometime
> >>> not taking into account and reported back to the upper level
> >>> of interpretation of CCW instructions.
> >>>
> >>> It follows that accessing an invalid address does not trigger
> >>> a subchannel status program check to the guest as it should.
> >>>
> >>> Let's test the return values of ccw_dstream_write[_buf] and
> >>> ccw_dstream_read[_buf] and report it to the caller.
> >>>
> >>> Signed-off-by: Pierre Morel <pmorel@linux.ibm.com>
> >>
> >> Acked-by: Halil Pasic <pasic@linux.ibm.com>
> >>
> >> I did not look into the whole scsw.count stuff or into wether
> >> your changes to 3270 (look form <mark></mark> in the diff part) affect
> >> more than just ccw_dstream_*.
> >>
> >> I would have preferred this patch split up based on the intended effect
> >> and thus also subsystem (css, virtio-ccw, 3270), but I've alluded to
> >> that before, and since we are in a hurry I can live with it as is.
> >>
> >> Regards,
> >> Halil
> >>
> >>> ---
> >>> hw/char/terminal3270.c | 11 +++++--
> >>> hw/s390x/3270-ccw.c | 5 +++-
> >>> hw/s390x/css.c | 14 +++++----
> >>> hw/s390x/virtio-ccw.c | 66 ++++++++++++++++++++++++++++++------------
> >>> 4 files changed, 69 insertions(+), 27 deletions(-)
> >>>
> >>> diff --git a/hw/char/terminal3270.c b/hw/char/terminal3270.c
> >>> index a9a46c8ed3..82e85fac2e 100644
> >>> --- a/hw/char/terminal3270.c
> >>> +++ b/hw/char/terminal3270.c
> >>> @@ -200,9 +200,13 @@ static int read_payload_3270(EmulatedCcw3270Device *dev)
> >>> {
> >>> Terminal3270 *t = TERMINAL_3270(dev);
> >>> int len;
> >>> + int ret;
> >>>
> >>> len = MIN(ccw_dstream_avail(get_cds(t)), t->in_len);
> >>> - ccw_dstream_write_buf(get_cds(t), t->inv, len);
> >>> + ret = ccw_dstream_write_buf(get_cds(t), t->inv, len);
> >>> + if (ret < 0) {
> >>> + return ret;
> >>> + }
> >>> t->in_len -= len;
> >>>
> >>> return len;
> >>> @@ -260,7 +264,10 @@ static int write_payload_3270(EmulatedCcw3270Device *dev, uint8_t cmd)
> >>>
> >>> t->outv[out_len++] = cmd;
> >>> do {
> >>> - ccw_dstream_read_buf(get_cds(t), &t->outv[out_len], len);
> >>> + retval = ccw_dstream_read_buf(get_cds(t), &t->outv[out_len], len);
> >>> + if (retval < 0) {
> >>> + return retval;
> >>> + }
> >>> count = ccw_dstream_avail(get_cds(t));
> >>> out_len += len;
> >>>
> >>> diff --git a/hw/s390x/3270-ccw.c b/hw/s390x/3270-ccw.c
> >>> index 821319eee6..f3e7342b1e 100644
> >>> --- a/hw/s390x/3270-ccw.c
> >>> +++ b/hw/s390x/3270-ccw.c
> >>> @@ -31,6 +31,9 @@ static int handle_payload_3270_read(EmulatedCcw3270Device *dev, CCW1 *ccw)
> >>> }
> >>>
> >>> len = ck->read_payload_3270(dev);
> >>
> >> <mark>
> >>
> >>> + if (len < 0) {
> >>> + return len;
> >>> + }
> >>> ccw_dev->sch->curr_status.scsw.count = ccw->count - len;
> >>>
> >>
> >> </mark>
> >>
> >> Do we eventually update scsw.count?
> >
> > I think we can consider the contents of scsw.count 'unpredictable', no?
>
> I think so, the (len < 0) here will trigger a program check and the POP
> specifies the count as "not meaningful" in case of a program check.
Yes, that's what I meant.
>
>
> >
> >>
> >>> return 0;
> >>> @@ -50,7 +53,7 @@ static int handle_payload_3270_write(EmulatedCcw3270Device *dev, CCW1 *ccw)
> >>> len = ck->write_payload_3270(dev, ccw->cmd_code);
> >>>
> >>> if (len <= 0) {
> >>
> >> <mark>
> >>> - return -EIO;
> >>> + return len ? len : -EIO;
> >>
> >> </mark>
>
> Here we do not change the previous behavior.
> This problem, if it is one, is not related to not checking the dstream
> read/write functions.
I agree.
>
> >>
> >>> }
> >>>
> >>> ccw_dev->sch->curr_status.scsw.count = ccw->count - len;
> >>> diff --git a/hw/s390x/css.c b/hw/s390x/css.c
> >>> index fe47751df4..4149b8e5a7 100644
> >>
> >
>
next prev parent reply other threads:[~2021-04-09 10:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 16:32 [PATCH v2 0/1] s390x: css: report errors from ccw_dstream_read/write Pierre Morel
2021-04-08 16:32 ` [PATCH v2 1/1] " Pierre Morel
2021-04-09 8:38 ` Halil Pasic
2021-04-09 8:49 ` Cornelia Huck
2021-04-09 9:55 ` Pierre Morel
2021-04-09 10:11 ` Cornelia Huck [this message]
2021-04-09 10:27 ` Cornelia Huck
2021-04-09 10:32 ` Pierre Morel
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=20210409121102.2e7da357.cohuck@redhat.com \
--to=cohuck@redhat.com \
--cc=borntraeger@de.ibm.com \
--cc=david@redhat.com \
--cc=frankja@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=marcandre.lureau@redhat.com \
--cc=mst@redhat.com \
--cc=pasic@linux.ibm.com \
--cc=pbonzini@redhat.com \
--cc=pmorel@linux.ibm.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-s390x@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=thuth@redhat.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;
as well as URLs for NNTP newsgroup(s).