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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 10 Jul 2017 15:39:25 -0700
From:   Krister Johansen <kjlx@...pleofstupid.com>
To:     Thomas-Mich Richter <tmricht@...ux.vnet.ibm.com>
Cc:     Krister Johansen <kjlx@...pleofstupid.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        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 Mon, Jul 10, 2017 at 08:17:00AM +0200, Thomas-Mich Richter wrote:
> 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.
> 
> 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?

I think we're talking past one another.  If the container exits then the
inode numbers that identify mount namespace are referring to something
that is no longer valid.  There's no mount namespace to enter in order
to locate the binary objects.  They may be on a volume that's no longer
mounted.

I have a pair of patches in the existing set that copies the binary
objects into the buildid cache.  This lets you resolve the symbols after
the container has exited, provided that you recorded the buildids during
the trace.

If you apply all the patches in this set, you should be able to generate
traces that you can look at with script or report even after the process
has exited.  I've been able to do it in my tests, at least.

-K