linux-kernel - Re: [PATCH] lightnvm: pblk: fix error path in pblk_lines_alloc

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] [day] [month] [year] [list]

Date:   Thu, 21 Sep 2017 13:14:48 +0200
From:   Matias Bjørling <mb@...htnvm.io>
To:     Rakesh Pandit <rakesh@...era.com>,
        Javier González <jg@...htnvm.io>
Cc:     linux-block@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] lightnvm: pblk: fix error path in
 pblk_lines_alloc_metadata

On 09/21/2017 12:15 PM, Rakesh Pandit wrote:
> On Thu, Sep 21, 2017 at 11:56:46AM +0200, Javier González wrote:
>>> On 20 Sep 2017, at 21.50, Rakesh Pandit <rakesh@...era.com> wrote:
>>>
>>> Use appropriate memory free calls based on allocation type used and
>>> also fix number of times free is called if kmalloc fails.
>>>
>>> Signed-off-by: Rakesh Pandit <rakesh@...era.com>
>>> ---
>>> drivers/lightnvm/pblk-init.c | 8 ++++++--
>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/lightnvm/pblk-init.c b/drivers/lightnvm/pblk-init.c
>>> index 7cf4b53..470ef04 100644
>>> --- a/drivers/lightnvm/pblk-init.c
>>> +++ b/drivers/lightnvm/pblk-init.c
>>> @@ -624,12 +624,16 @@ static int pblk_lines_alloc_metadata(struct pblk *pblk)
>>>
>>> fail_free_emeta:
>>> 	while (--i >= 0) {
>>> -		vfree(l_mg->eline_meta[i]->buf);
>>> +		if (l_mg->emeta_alloc_type == PBLK_VMALLOC_META)
>>> +			vfree(l_mg->eline_meta[i]->buf);
>>> +		else
>>> +			kfree(l_mg->eline_meta[i]->buf);
>>> 		kfree(l_mg->eline_meta[i]);
>>> 	}
>>>
>>> +	i = PBLK_DATA_LINES;
>>> fail_free_smeta:
>>> -	for (i = 0; i < PBLK_DATA_LINES; i++)
>>> +	while (--i >= 0)
>>> 		kfree(l_mg->sline_meta[i]);
>>
>> It is safe to use kfree on NULL pointers. No need to do this. You can
>> either send a new patch, or we can change it when picking it up.
> 
> Yes, that would be great if this is adjusted while picking up.
> 
>>
>>>
>>> 	return -ENOMEM;
>>> --
>>> 2.5.0
>>
>> Rest looks good.
>>
>>
>> Reviewed-by: Javier González <javier@...xlabs.com>
>>
> 
> Thanks,
> 

Thanks Rakesh. I queued it up.