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:	Tue, 17 May 2016 21:04:38 -0600
From:	David Ahern <dsahern@...il.com>
To:	Hekuang <hekuang@...wei.com>, peterz@...radead.org,
	mingo@...hat.com, acme@...nel.org,
	alexander.shishkin@...ux.intel.com, jolsa@...hat.com,
	wangnan0@...wei.com, jpoimboe@...hat.com, ak@...ux.intel.com,
	eranian@...gle.com, namhyung@...nel.org, adrian.hunter@...el.com,
	sukadev@...ux.vnet.ibm.com, masami.hiramatsu.pt@...achi.com,
	tumanova@...ux.vnet.ibm.com, kan.liang@...el.com,
	penberg@...nel.org
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 3/7 UPDATE] perf tools: Add option for the path of
 buildid dsos under symfs

On 5/17/16 8:48 PM, Hekuang wrote:
>> I don't understand why dso-prefix option is needed? Why make me type
>> yet more options to the analysis command? Why can't the directory be
>> located under the symfs tree in a known location and populated the
>> same way it is without symfs?
>>
>>
> Because the default buidid folder path is $HOME/.debug/.buildid,
> and this $HOME is on the target machine, not the same as $HOME
> on the host. Without that option, we need to copy $HOME/.debug/.buildid
> to the 'known location in symfs', that's also an extra work.
>

My argument for symfs is that $HOME is not relevant or if it is the path 
is symfs/$HOME. The use case is dealing with countless images -- some 
development, some production. I should be able to nuke the symfs when 
the analysis is done and everything related to it is gone. With the 
$HOME/.debug path it just grows on and on with no real means of pruning it.

If the vdsos are for a particular symfs then why aren't the vdso's under 
it in a known location?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ