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: <20201117151651.GD1216482@krava>
Date:   Tue, 17 Nov 2020 16:16:51 +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 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

jirka

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ