From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Daley Subject: Re: [PATCH 12/28] libxl: only free cputopology if it was allocated in libxl__get_numa_candidate Date: Wed, 18 Sep 2013 21:30:57 +1200 Message-ID: References: <1379475484-25993-1-git-send-email-mattjd@gmail.com> <1379475484-25993-13-git-send-email-mattjd@gmail.com> <1379491026.18543.41.camel@Abyss> <1379495450.18543.84.camel@Abyss> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1379495450.18543.84.camel@Abyss> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: "xen-devel@lists.xen.org" , Ian Jackson , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Wed, Sep 18, 2013 at 9:10 PM, Dario Faggioli wrote: > On mer, 2013-09-18 at 20:42 +1200, Matthew Daley wrote: >> On Wed, Sep 18, 2013 at 7:57 PM, Dario Faggioli >> >> > Also, if something like that would be necessary, why doing it only for >> > tinfo and not for ninfo as well? I'm not that into coverity, but I don't >> > think I see why it treats the two of them differently... :-O >> >> Not sure. Probably because if ninfo == NULL, we return directly out of >> the function instead of goto-ing the cleanup. >> > Right, which, now that I've seen it, calls for a patch making it go > through cleanup too! :-P > > Anyway, for libxl_cputopology_list_free() (and also for > libxl_numainfo_list_free() if I really decide to patch it to make it > more "libxl style"), especially considering that something similar to > this happens in other places (as we're seeing in 13/28), is there > anything we can do for preventing this to come up again in future scans? Simply marking the Defects in Coverity as "False Positive" (which I just did before) prevents them from bugging us in the future. A quick grep shows that the functions are only called in ~11 spots AFAICT; that's still small enough to sensibly allow manual overriding if any of the other invocations are complained about. However, I can't see any others from a quick look (I haven't figured out a way, if there is one, to go from a function *out* to its invocations which are tagged, unfortunately.) - Matthew