All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cornelia Huck <cohuck@redhat.com>
To: Janosch Frank <frankja@linux.ibm.com>
Cc: Collin Walling <walling@linux.ibm.com>,
	mst@redhat.com, David Hildenbrand <david@redhat.com>,
	qemu-devel@nongnu.org, pasic@linux.ibm.com,
	borntraeger@de.ibm.com, qemu-s390x@nongnu.org,
	svens@linux.ibm.com, pbonzini@redhat.com, mihajlov@linux.ibm.com,
	rth@twiddle.net
Subject: Re: [PATCH v1 2/8] s390/sclp: check sccb len before filling in data
Date: Wed, 13 May 2020 10:16:37 +0200	[thread overview]
Message-ID: <20200513101637.2f325838.cohuck@redhat.com> (raw)
In-Reply-To: <5ed5bc04-e4e3-21ca-057f-a978ef411ad8@linux.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 2252 bytes --]

On Wed, 13 May 2020 09:43:37 +0200
Janosch Frank <frankja@linux.ibm.com> wrote:

> On 5/12/20 6:01 PM, Cornelia Huck wrote:
> > On Mon, 11 May 2020 17:02:06 +0200
> > David Hildenbrand <david@redhat.com> wrote:
> >   
> >> On 11.05.20 16:50, Janosch Frank wrote:  
> >>> On 5/11/20 4:44 PM, David Hildenbrand wrote:    
> >>>> On 11.05.20 16:36, Janosch Frank wrote:    
> >>>>> On 5/9/20 1:08 AM, Collin Walling wrote:    
> >>>>>> The SCCB must be checked for a sufficient length before it is filled
> >>>>>> with any data. If the length is insufficient, then the SCLP command
> >>>>>> is suppressed and the proper response code is set in the SCCB header.
> >>>>>>
> >>>>>> Signed-off-by: Collin Walling <walling@linux.ibm.com>    
> >>>>>
> >>>>> Fixes tag?  
> > 
> > Probably
> > 
> > Fixes: 832be0d8a3bb ("s390x: sclp: Report insufficient SCCB length")
> > 
> > ?
> >   
> >>>>> Reviewed-by: Janosch Frank <frankja@linux.ibm.com>    
> >>>>
> >>>> This is not a fix AFAIKs.
> >>>> sclp_service_call()/sclp_service_call_protected() always supplies a full
> >>>> SCCB of exactly 4k size.
> >>>>    
> >>>
> >>> We don't check for QEMU's 4k buffer here, but for the length that was
> >>> specified by the guest.
> >>>
> >>> It's valid for the guest to request cpu info and state that its buffer
> >>> is only 1k. We can't write everything in 1k if we have ~200 cpus, so
> >>> we'll report the insufficient length rc.
> >>>
> >>> What he fixes here is the time of the length check, it should be done
> >>> before any changes are being done to the work_sccb.    
> >>
> >> I don't have access to the spec, especially, if the guest can expect
> >> nothing else in the sccb to change in case we report an error code. So
> >> whatever you tell me, I have to trust you :)  
> > 
> > Same here. Sounds plausible, but I have to trust the folks with the
> > documentation :)
> >   
> 
> The AR states that:
> * Command validity check (has prio over length, as length is dependent
> on command)
> * boundary (if extended-length is not available)
> * Sufficient length check
> 
> are done before "any other command action is taken".
> If a test fails the command is suppressed.

Thanks, makes sense.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-05-13  8:18 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-08 23:08 [PATCH v1 0/8] s390: Extended-Length SCCB & DIAGNOSE 0x318 Collin Walling
2020-05-08 23:08 ` [PATCH v1 1/8] s390/sclp: remove SCLPDevice param from prepare_cpu_entries Collin Walling
2020-05-11 14:37   ` Janosch Frank
2020-05-12  7:17   ` David Hildenbrand
2020-05-08 23:08 ` [PATCH v1 2/8] s390/sclp: check sccb len before filling in data Collin Walling
2020-05-11 14:36   ` Janosch Frank
2020-05-11 14:44     ` David Hildenbrand
2020-05-11 14:47       ` Collin Walling
2020-05-11 14:50       ` Janosch Frank
2020-05-11 15:02         ` David Hildenbrand
2020-05-12 16:01           ` Cornelia Huck
2020-05-12 16:16             ` Collin Walling
2020-05-12 16:24               ` Cornelia Huck
2020-05-12 16:25                 ` Collin Walling
2020-05-13  7:43             ` Janosch Frank
2020-05-13  8:16               ` Cornelia Huck [this message]
2020-05-14 17:22                 ` Collin Walling
2020-05-18 11:43   ` David Hildenbrand
2020-05-08 23:08 ` [PATCH v1 3/8] s390/sclp: rework sclp boundary and length checks Collin Walling
2020-05-12  7:21   ` David Hildenbrand
2020-05-12 14:55     ` Collin Walling
2020-05-13  7:00       ` Cornelia Huck
2020-05-14 17:23         ` Collin Walling
2020-05-08 23:08 ` [PATCH v1 4/8] s390/sclp: read sccb from mem based on sccb length Collin Walling
2020-05-12  7:26   ` David Hildenbrand
2020-05-12 14:46     ` Collin Walling
2020-05-08 23:08 ` [PATCH v1 5/8] s390/sclp: use cpu offset to locate cpu entries Collin Walling
2020-05-08 23:08 ` [PATCH v1 6/8] s390/sclp: add extended-length sccb support for kvm guest Collin Walling
2020-05-08 23:08 ` [PATCH v1 7/8] s390/kvm: header sync for diag318 Collin Walling
2020-05-13  7:05   ` Cornelia Huck
2020-05-13 22:44     ` Collin Walling
2020-05-08 23:08 ` [PATCH v1 8/8] s390: diagnose 318 info reset and migration support Collin Walling
2020-05-09  8:07 ` [PATCH v1 0/8] s390: Extended-Length SCCB & DIAGNOSE 0x318 no-reply
2020-05-12 16:08 ` Cornelia Huck
2020-05-12 16:20   ` Collin Walling

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=20200513101637.2f325838.cohuck@redhat.com \
    --to=cohuck@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=david@redhat.com \
    --cc=frankja@linux.ibm.com \
    --cc=mihajlov@linux.ibm.com \
    --cc=mst@redhat.com \
    --cc=pasic@linux.ibm.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    --cc=svens@linux.ibm.com \
    --cc=walling@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.