linux-kernel - Re: [PATCH v3] perf tools: Introduce perf

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, 4 Dec 2015 22:15:16 +0900
From:	Namhyung Kim <namhyung@...nel.org>
To:	平松雅巳 / HIRAMATU，MASAMI 
	<masami.hiramatsu.pt@...achi.com>
Cc:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Jiri Olsa <jolsa@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH v3] perf tools: Introduce perf_thread for backtrace

Hi Masami,

On Thu, Dec 03, 2015 at 07:13:15AM +0000, 平松雅巳 / HIRAMATU，MASAMI wrote:
> From: Namhyung Kim [mailto:namhyung@...nel.org]
> >
> >On Thu, Dec 03, 2015 at 12:15:12AM +0000, 平松雅巳 / HIRAMATU，MASAMI wrote:
> >> >From: Namhyung Kim [mailto:namhyung@...il.com] On Behalf Of Namhyung Kim
> >> >
> >> >Backtrace is a crucial info for debugging.  And upcoming refcnt
> >> >tracking facility also wants to use it.
> >>
> >> Note that the refcnt backtrace symbol resolution will work at
> >> exit. This means that it can not depend on the feature in perf
> >> tools itself. (and of course, since the refcnt tries to find unused
> >> objects in perf tools at exit, if we use perf_thread, it will
> >> detect the objects related to the perf_thread are leaked)
> >
> >Hmm.. right.
> >
> >I think we can leave the perf_thread outside of refcnt infrastructure.
> >IOW it should be created before refcnt debugging is activated and
> >released after refcnt is done.  What do you think?
> 
> Would you mean we don't debug the objects related to a perf_thread?
> It will mean that you don't debug anything, since perf_thread involves
> most of refcnt using objects, like dso, map, map_groups etc. And some
> bugs are actually found at where those objects are handled.
> 
> I would not like to care about the output quality of the backtrace_symbols.
> I only need the top 2-3 addresses of the backtrace buffer, because I have
> (eu-)addr2line command to find the actual source code lines from those
> addresses :). If you need, I can also provide an address decoder awk/shell
> script for that.
> 
> Instead, I prefer to avoid complexity on the "debugging feature"(because
> it can introduce new bugs,) and make it more robust (e.g. if we failed to
> get symbol, just shows the raw address)
> 
> BTW, the robustness is a key point for debugging. Please consider the case
> that you hit an error on the objects in the perf_thread, it could cause
> double fault(segv again) on the same object. That is what I actually don't
> want.

I understand your point.  If you object, I won't insist it strongly.

It's possible there's a bug in perf_thread symbol resolution.  But
it's pretty straightforward and simple use case so if there's a bug in
that code, it should be found beforehand IMHO.

Thanks,
Namhyung
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/