linux-kernel - RE: [PATCH 1/1] perf,tools: add time out to force stop endless mmap processing

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]

Message-ID: <37D7C6CF3E00A74B8858931C1DB2F07701876ECA@SHSMSX103.ccr.corp.intel.com>
Date:	Sat, 13 Jun 2015 14:59:56 +0000
From:	"Liang, Kan" <kan.liang@...el.com>
To:	David Ahern <dsahern@...il.com>, Andi Kleen <andi@...stfloor.org>
CC:	Arnaldo Carvalho de Melo <acme@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Huang, Ying" <ying.huang@...el.com>
Subject: RE: [PATCH 1/1] perf,tools: add time out to force stop endless mmap
 processing


> 
> > The maps information is not critical for sampling.
> 
> But is for correlating the addresses in those samples.

We still have the maps information for other threads in system.
Only part of the information for some thread is lost.

> 
> >
> > If task_diag does not solve this problem, I think we still need a time
> > out to force stop endless mmap processing. It's the simplest working
> > solution so far.
> 
> I disagree with the timeout. For example an overloaded system where
> perf is not getting scheduled could trigger the same.

It's not a perfect solution for all tools. But a working solution for perf.
Without timeout, we get nothing from perf top/record.
With timeout, we can do sampling. We can correlate the addresses in
most samples. It's better than nothing.

> 
> Also, in the spirit of perf if you are going to drop information you need to
> generate an event that says information was lost and have the analysis
> tools show a message that information was lost. You can't simply bail out
> and have "[unknown]" shown for symbols / dsos. I get tons of user
> comments about perf showing callchains properly; the proposed patch just
> adds to that confusion.

Currently, it will print a warning in perf top/record. I think I can do more and
print warning in perf_session__warn_about_errors as Arnaldo suggested.
 
Thanks,
Kan


> 
> David
--
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/