linux-kernel - Re: [PATCH 2/7] perf trace: add support for pagefault tracing

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: <20140624124620.GB16950@stfomichev-desktop.yandex.net>
Date:	Tue, 24 Jun 2014 16:46:20 +0400
From:	Stanislav Fomichev <stfomichev@...dex-team.ru>
To:	Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:	a.p.zijlstra@...llo.nl, paulus@...ba.org, mingo@...hat.com,
	dsahern@...il.com, jolsa@...hat.com,
	xiaoguangrong@...ux.vnet.ibm.com, yangds.fnst@...fujitsu.com,
	adrian.hunter@...el.com, namhyung@...nel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/7] perf trace: add support for pagefault tracing

> > I think we may try to print [ip.dso+ip.offset] if we can't resolve ip symbol,
> > but I don't want dso@...bol+offset because if we have symbol, dso is
> > probably (?) redundant (ok, at least for me).
> 
> Well, I don't think it is :-)
> 
> dso->short_name should disambiguate 99.9% of the cases tho. Perhaps we
> can use --verbose, as in other places, to switch using dso->long_name,
> for cases where multiple versions of a library are used, some in non
> standard paths, which sometimes puzzles people looking at the tools
> output.
If we use --verbose it will result in noise besides short/long names
(like looking up debug symbols, etc).
But I'm still not convinced we need to always print dso of ip, we already have
target process and symbol (if we have dbg symbols), this should be
enough to understand what code path triggered fault.

> > It also seems we don't need to resolve symbol of pagefault address
> 
> Well, in some cases if we can resolve to a variable, why not?
If we fault into data map, we resolve to nothing, right? But if we
fault into some executable map, we can resolve some symbol. But is it
really useful to know (because for me it's much more interesting to know
which dso and offset we fault into, not the actual symbol)?

What I think makes sense it to have current (default) format:
[ip.sym+ip.offs] => [addr.dso.long+addr.offs]

And --verbose format, which will use dso.long@...bol+offset for addr and ip.
So by default we have somewhat readable and concise information, and if we
need to gather all possible details we may use --verbose. What do you
think?
--
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/