linux-kernel - Re: [PATCH v4 1/2] drivers/s390/char: Add Ultravisor io device

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 13 May 2022 14:35:00 +0200
From:   Steffen Eiden <seiden@...ux.ibm.com>
To:     Claudio Imbrenda <imbrenda@...ux.ibm.com>
Cc:     Greg KH <greg@...ah.com>, Heiko Carstens <hca@...ux.ibm.com>,
        Alexander Gordeev <agordeev@...ux.ibm.com>,
        Shuah Khan <shuah@...nel.org>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Janosch Frank <frankja@...ux.ibm.com>,
        David Hildenbrand <david@...hat.com>,
        Nico Boehr <nrb@...ux.ibm.com>, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH v4 1/2] drivers/s390/char: Add Ultravisor io device



On 5/13/22 10:37, Claudio Imbrenda wrote:
> On Fri, 13 May 2022 09:45:39 +0200
> Steffen Eiden <seiden@...ux.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]