All of lore.kernel.org
 help / color / mirror / Atom feed
From: Janosch Frank <frankja@linux.ibm.com>
To: David Hildenbrand <david@redhat.com>,
	Collin Walling <walling@linux.ibm.com>,
	qemu-devel@nongnu.org, qemu-s390x@nongnu.org
Cc: mst@redhat.com, cohuck@redhat.com, pasic@linux.ibm.com,
	borntraeger@de.ibm.com, 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: Mon, 11 May 2020 16:50:39 +0200	[thread overview]
Message-ID: <05ab2e59-10c0-c7df-c014-b54883ddccd3@linux.ibm.com> (raw)
In-Reply-To: <737869a8-13b2-1831-00c6-629d5a109d9c@redhat.com>


[-- Attachment #1.1: Type: text/plain, Size: 1047 bytes --]

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?
>> 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.


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

  parent reply	other threads:[~2020-05-11 14:53 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 [this message]
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
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=05ab2e59-10c0-c7df-c014-b54883ddccd3@linux.ibm.com \
    --to=frankja@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=david@redhat.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.