Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
Message-ID: <5674a855-456f-d9b8-661f-49908aad2025@linux.ibm.com>
Date:   Fri, 13 May 2022 14:35:00 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.0
Subject: Re: [PATCH v4 1/2] drivers/s390/char: Add Ultravisor io device
Content-Language: en-US
To:     Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc:     Greg KH <greg@kroah.com>, Heiko Carstens <hca@linux.ibm.com>,
        Alexander Gordeev <agordeev@linux.ibm.com>,
        Shuah Khan <shuah@kernel.org>,
        Christian Borntraeger <borntraeger@linux.ibm.com>,
        Janosch Frank <frankja@linux.ibm.com>,
        David Hildenbrand <david@redhat.com>,
        Nico Boehr <nrb@linux.ibm.com>, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org, kvm@vger.kernel.org
References: <20220510144724.3321985-1-seiden@linux.ibm.com>
 <20220510144724.3321985-2-seiden@linux.ibm.com>
 <20220512163327.2c86cab1@p-imbrenda>
 <80afde93-b9cf-f6c4-da40-3385d7f6741b@linux.ibm.com>
 <20220513103758.5a4baf7c@p-imbrenda>
From:   Steffen Eiden <seiden@linux.ibm.com>
Organization: IBM
In-Reply-To: <20220513103758.5a4baf7c@p-imbrenda>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 5/13/22 10:37, Claudio Imbrenda wrote:
> On Fri, 13 May 2022 09:45:39 +0200
> Steffen Eiden <seiden@linux.ibm.com> wrote:
> 
>> On 5/12/22 16:33, Claudio Imbrenda wrote:
>>
>> [snip]
>>
>>>> +/*
>>>> + * IOCTL entry point for the Ultravisor device.
>>>> + */
>>>> +static long uvio_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
>>>> +{
>>>> +	void __user *argp = (void __user *)arg;
>>>> +	struct uvio_ioctl_cb *uv_ioctl;
>>>> +	long ret;
>>>> +
>>>> +	ret = -ENOMEM;
>>>> +	uv_ioctl = vzalloc(sizeof(*uv_ioctl));
>>> struct uvio_ioctl_cb is rather small, couldn't you just allocate it on
>>> the stack?
>>>    
>> IIRC it was on stack in some previous version. We then had a discussion
>> earlier about this triggered by the inverse comment and decided to not
>> use the stack.
> 
> ok fair enough
> 
> but what's the reason for a vzalloc instead of a kzalloc, when the
> allocation is surely going to be small?
> 
We had no strong reasons against or for vzalloc/kzalloc.
If you want me to change it to kzalloc I can do it. I still
have no strong opinion on that.

>> [snip]