linux-kernel - Re: [PATCH 1/1] infiniband: Remove redundant NULL check before kfree

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]

Message-ID: <559DA301.20203@redhat.com>
Date:	Wed, 08 Jul 2015 18:24:01 -0400
From:	Doug Ledford <dledford@...hat.com>
To:	maninder1.s@...sung.com
CC:	Sean Hefty <sean.hefty@...el.com>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	David Miller <davem@...emloft.net>,
	"roland@...estorage.com" <roland@...estorage.com>,
	Matan Barak <matanb@...lanox.com>,
	Moni Shoua <monis@...lanox.com>,
	"jackm@....mellanox.co.il" <jackm@....mellanox.co.il>,
	Yishai Hadas <yishaih@...lanox.com>,
	"eranbe@...lanox.com" <eranbe@...lanox.com>,
	Ira Weiny <ira.weiny@...el.com>,
	linux-rdma <linux-rdma@...r.kernel.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	PANKAJ MISHRA <pankaj.m@...sung.com>
Subject: Re: [PATCH 1/1] infiniband: Remove redundant NULL check before kfree

On 07/08/2015 12:23 AM, Maninder Singh wrote:
> Hello,
> 
>>> +			for (i = 0; i < dev->caps.num_ports; i++)
>>> +				kfree(dm[i]);
>>> 			goto out;
>>> 		}
>>> 	}
>>> --
>>> 1.7.9.5
>>>
>>
>> If you are going to change this, you might as well make it 100% correct:
>>
>> i—-;
>> while (i >= 0)
>> 	kfree(dm[i]);
>>
>> Then you don’t have to worry about whether kfree works on NULL, every item you free will be guaranteed to be non-NULL.
> Thanks for suggestion :)
> Sent new patch with described changes, I was thinking one more thing.
> 
> In below code :-
>         if (!ibdev->sriov.is_going_down)
>             queue_work(ibdev->sriov.demux[i].ud_wq, &dm[i]->work);
>         spin_unlock_irqrestore(&ibdev->sriov.going_down_lock, flags);
>     }
> out:
>     kfree(dm);
>     return;
> 
> dm is freed after queue_work, is it correct to free dm when other dm[i] are allocated ? i did not get it.

The dm is just there to give an easy way to refer to a variable number
of work structs.  The flow is supposed to be something like this:

alloc(dm)
for(i=0;i<num_qps;i++)
    dm[i] == alloc(work item);
for(i=0;i<num_qps;i++)
    init dm[i] work item
    queue dm[i] work item
free(dm)

In this scenario, all of the dm[i] items should be queued to delayed
work.  When that work completes, it should then free these structs.  So,
yes, the dm variable itself is just a temporary means of keeping all
those work struct pointers together.  However, your question caused me
to look closely here, and I see that there is a bug.  In particular, if
we check the sriov.is_going_down and as a result *don't* queue a work
item, then we end up leaking that work struct.  In addition, I think
there is room to optimize this routine considerably.  I'll post a patch
for that in a minute.

-- 
Doug Ledford <dledford@...hat.com>
              GPG KeyID: 0E572FDD



Download attachment "signature.asc" of type "application/pgp-signature" (885 bytes)