linux-kernel - Re: [PATCH v2 tip/perf/core 1/6] perf symbols: find symbols in different mount namespace

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: <381cf00c-c540-8c20-7182-ecdd94f2d81c@linux.vnet.ibm.com>
Date:   Mon, 10 Jul 2017 08:17:00 +0200
From:   Thomas-Mich Richter <tmricht@...ux.vnet.ibm.com>
To:     Krister Johansen <kjlx@...pleofstupid.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Brendan Gregg <brendan.d.gregg@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 tip/perf/core 1/6] perf symbols: find symbols in
 different mount namespace

On 07/07/2017 09:36 PM, Krister Johansen wrote:
> On Thu, Jul 06, 2017 at 04:41:30PM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Wed, Jul 05, 2017 at 06:48:08PM -0700, Krister Johansen escreveu:
>>> Teach perf how to resolve symbols from binaries that are in a different
>>> mount namespace from the tool.  This allows perf to generate meaningful
>>> stack traces even if the binary resides in a different mount namespace
>>> from the tool.
>>
>> I was trying to find a way to test after applying each of the patches in
>> this series, when it ocurred to me that if a process that appears on a
>> perf.data file has exit, how can we access /proc/%ITS_PID/something?
> 
> You're correct.  We can't access /proc/<PID>/whatever once the process
> has exited.  That was the impeteus for patches 4 and 6, which allow us
> to capture the binary (and debuginfo, if it exists) into the buildid
> cache so that if we do have a trace that exists after a process or
> container exists, we'll still be able to resolve some of the symbols.
> 
> -K
> 

Any ideas on how to extend this to be able to resolve symbols after
the process/container exited?
I believe it boils down on how to interpret the mnt inode number in the
PERF_RECORD_NAMESPACE record...
Can this be done post-mortem? Maybe the PERF_RECORD_NAMESPACE record
has to contain more data than just the inode number?

-- 
Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany
--
Vorsitzende des Aufsichtsrats: Martina Koederitz 
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294