From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755213AbdJSOcr (ORCPT ); Thu, 19 Oct 2017 10:32:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39854 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754930AbdJSOc1 (ORCPT ); Thu, 19 Oct 2017 10:32:27 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 563C4806A6 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Thu, 19 Oct 2017 09:32:26 -0500 From: Josh Poimboeuf To: Kamalesh Babulal Cc: linux-kernel@vger.kernel.org, Ingo Molnar Subject: Re: [PATCH] objtool: Fix memory leak in decode_instructions() Message-ID: <20171019143226.latzeyhoo3d7dqfo@treble> References: <1507798934-18140-1-git-send-email-kamalesh@linux.vnet.ibm.com> <20171012161016.z4ytxmm2rbfiewbl@treble> <1297c97f-844b-0631-311d-8e3742f2f74f@linux.vnet.ibm.com> <20171013050630.cdax2kxj3yqnaton@treble> <8cec1109-8749-0f77-14ca-4bd8e92ebd9d@linux.vnet.ibm.com> <20171019143137.bbte3nwa2pq6uywb@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20171019143137.bbte3nwa2pq6uywb@treble> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 19 Oct 2017 14:32:27 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Oct 19, 2017 at 09:31:37AM -0500, Josh Poimboeuf wrote: > On Fri, Oct 13, 2017 at 11:20:58AM +0530, Kamalesh Babulal wrote: > > On Friday 13 October 2017 10:36 AM, Josh Poimboeuf wrote: > > > On Fri, Oct 13, 2017 at 10:14:36AM +0530, Kamalesh Babulal wrote: > > > > On Thursday 12 October 2017 09:40 PM, Josh Poimboeuf wrote: > > > > > On Thu, Oct 12, 2017 at 02:32:14PM +0530, Kamalesh Babulal wrote: > > > > > > free the allocated insn before returning, when an error occurs > > > > > > before adding insn to file->insn_list. > > > > > > > > > > > > Signed-off-by: Kamalesh Babulal > > > > > > > > > > Any chance you're working on porting objtool to ppc64le? :-) > > > > > > > > > > Acked-by: Josh Poimboeuf > > > > > > > > > > > > > Thanks for the review. I have started working on it :) > > > > > > Good! Let me know if you have any questions. > > > > Thank you, I am sure I will have lots of them. > > > > > > > > I originally wrote objtool with arch-independence in mind, though with > > > the new "objtool 2.0" rewrite, it unfortunately became more > > > x86-specific. > > > > > > I was hoping to work on making it more arch-independent, and then start > > > porting it to other arches, but it may be a few months before I have the > > > time to do so. So any work you want to there would be great. > > > > > > > Sure, will keep that in mind to abstract arch-independent code in to common > > files and push arch-dependent code into arch/ directory for both > > ppc64le/x86. > > Kamalesh, since you might be working on this soon, here's a bit of a > brain dump in case it helps. > > I have a vague idea for eventually improving objtool, which might make > arch-independence easier. I wonder if we could use a GCC plugin to add > annotations in special sections, which are then read by objtool to help > it understand what's going on in the code. > > I suspect the plugins would need to be arch-specific. But then maybe > that would allow objtool itself to be completely arch-independent. > Eventually, if we had similar clang plugins, objtool could become > compiler-independent as well. > > Unfortunately I haven't had a chance to think about it any more deeply > than that. Just something to think about. > > Or maybe it makes sense to port objtool to ppc first, before trying to > abstract the arch-specific parts into plugins. I dunno. > > Also, another idea that has been suggested, is to use DWARF data as > input to objtool. I have my doubts about that idea, but if it worked, > that might be another way to help objtool achieve arch-independence. > > For a previous discussion of these ideas, see: > > https://lkml.kernel.org/r/20170831044209.4hodx2dasad66yab@treble Also, any chance you'll be in Prague for the conferences next week? If so, we could discuss it more in person. -- Josh