All of lore.kernel.org
 help / color / mirror / Atom feed
From: Collin Walling <walling@linux.ibm.com>
To: Cornelia Huck <cohuck@redhat.com>
Cc: frankja@linux.ibm.com, David Hildenbrand <david@redhat.com>,
	mst@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 3/8] s390/sclp: rework sclp boundary and length checks
Date: Thu, 14 May 2020 13:23:15 -0400	[thread overview]
Message-ID: <8acc1593-535d-bf1a-3129-bbb21d1d060a@linux.ibm.com> (raw)
In-Reply-To: <20200513090000.4272ddab.cohuck@redhat.com>

On 5/13/20 3:00 AM, Cornelia Huck wrote:
> On Tue, 12 May 2020 10:55:56 -0400
> Collin Walling <walling@linux.ibm.com> wrote:
> 
>> On 5/12/20 3:21 AM, David Hildenbrand wrote:
>>> On 09.05.20 01:08, Collin Walling wrote:  
> 
>>>> +static bool check_sufficient_sccb_len(SCCB *sccb, int size)  
>>>
>>> "has_sufficient_sccb_len" ?
>>>   
>>>> +{
>>>> +    MachineState *ms = MACHINE(qdev_get_machine());
>>>> +    int required_len = size + ms->possible_cpus->len * sizeof(CPUEntry);  
>>>
>>> Rather pass in the number of cpus instead. Looking up the machine again
>>> in here is ugly.  
>>
>> prepare_cpu_entries also looks up the machine again. Should I squeeze
>> in a cleanup where we pass the machine to that function too (perhaps
>> in the "remove SCLPDevice" patch)?
> 
> sclp_read_cpu_info() does not have the machine handy, so you'd need to
> move machine lookup there; but I think it's worth getting rid of
> duplicate lookups.
> 

Sounds good, then. I'll propose a change to patch 1 that removes the
unused SCLPDevice param and accepts a MachineState instead. Should make
things a bit cleaner :)

>>
>>>   
>>>> +
>>>> +    if (be16_to_cpu(sccb->h.length) < required_len) {
>>>> +        sccb->h.response_code = cpu_to_be16(SCLP_RC_INSUFFICIENT_SCCB_LENGTH);
>>>> +        return false;
>>>> +    }
>>>> +    return true;
>>>> +}
>>>> +
> 
> 


-- 
--
Regards,
Collin

Stay safe and stay healthy


  reply	other threads:[~2020-05-14 17:26 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
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 [this message]
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=8acc1593-535d-bf1a-3129-bbb21d1d060a@linux.ibm.com \
    --to=walling@linux.ibm.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.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 \
    /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.