linux-kernel - Re: [PATCH 13/24] perf tools: Allow mmap2 event to synthesize kernel image

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: <20201117204537.GH1216482@krava>
Date:   Tue, 17 Nov 2020 21:45:37 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Jiri Olsa <jolsa@...nel.org>, lkml <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Ingo Molnar <mingo@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Michael Petlan <mpetlan@...hat.com>,
        Song Liu <songliubraving@...com>,
        Ian Rogers <irogers@...gle.com>,
        Stephane Eranian <eranian@...gle.com>,
        Alexey Budankov <alexey.budankov@...ux.intel.com>,
        Andi Kleen <ak@...ux.intel.com>,
        Adrian Hunter <adrian.hunter@...el.com>
Subject: Re: [PATCH 13/24] perf tools: Allow mmap2 event to synthesize kernel
 image

On Tue, Nov 17, 2020 at 02:43:33PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 17, 2020 at 04:16:51PM +0100, Jiri Olsa escreveu:
> > On Tue, Nov 17, 2020 at 09:44:37AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Tue, Nov 17, 2020 at 12:00:42PM +0100, Jiri Olsa escreveu:
> > > > Allow mmap2 event to synthesize kernel image,
> > > > so we can synthesize kernel build id data in
> > > > following changes.
> > > > 
> > > > It's enabled by new symbol_conf.buildid_mmap2
> > > > bool, which will be switched in following
> > > > changes.
> > > 
> > > Why make this an option? MMAP2 goes back years:
> > > 
> > > 13d7a2410fa637f45 (Stephane Eranian         2013-08-21 12:10:24 +0200  904)      * The MMAP2 records are an augmented version of MMAP, they add
> > > 13d7a2410fa637f45 (Stephane Eranian         2013-08-21 12:10:24 +0200  905)      * maj, min, ino numbers to be used to uniquely identify each mapping
> > > 
> > > Also we unconditionally generate MMAP2 events if the kernel supports it,
> > > from evsel__config():
> > > 
> > >   attr->mmap  = track;
> > >   attr->mmap2 = track && !perf_missing_features.mmap2;
> > > 
> > > So perhaps we should reuse that logic? I.e. use mmap2 if the kernel
> > > supports it?
> > 
> > mmap2 itself is not a problem, the problem is the new
> > bit (PERF_RECORD_MISC_MMAP_BUILD_ID) that says there's
> > build id in mmap2.. older perf tool won't understand
> > that and report will crash
> 
> Is this theoretical or have you experienced it?
> 
> Would be good to tweak the perf.data reader code to not crash on unknown
> bits like that :-\
> 
> But by looking at machine__process_mmap2_event() I couldn't imagine how
> that would crash.
> 
> It would get bogus maj, min, ino, ino_generation, but probably that
> wouldn't make it crash.

right, I shouldn't said crash, sry ;-) but bogus values are worse
than that anyway

jirka