linux-kernel - Re: heads up: moving intel-pt-decoder/Build header checks to check

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] [day] [month] [year] [list]

Message-ID: <20180530125926.GC20886@kernel.org>
Date:   Wed, 30 May 2018 09:59:26 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     Jiri Olsa <jolsa@...nel.org>, Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-perf-users@...r.kernel.org
Subject: Re: heads up: moving intel-pt-decoder/Build header checks to
 check_headers.sh

Em Wed, May 30, 2018 at 09:30:50AM +0300, Adrian Hunter escreveu:
> On 29/05/18 16:48, Arnaldo Carvalho de Melo wrote:
> > 	We've made tools/perf/check-headers.sh the mechanism to check
> > for drift on kernel file copies we have in tools/, and it assumes that
> > if we have tools/a/b/c/d, then it came from a/b/c/d in the kernel
> > sources, e.g. a copy of the kernel's arch/x86/lib/x86-opcode-map.txt
> > would be in tools/arch/x86/lib/x86-opcode-map.txt.

> > 	That is not the case with the intel-pt-decoder, so I'm thinking
> > about moving those files to comply with the model used for other copies,
> > as having it in util/intel-pt-decoder/ isn't strictly required, i.e.
> > those files could conceivably be used for other purposes besides
> > decoding intel-pt traces, say for disassembly/annotate, that albeit not
> > planned (at least by me) for the near future, would be something
> > interesting to investigate doing.

> > 	IIRC Ingo was the one to point me out this, and now I saw the
> > warning about it being different flying by in the middle of the build,
> > differently from what is done by check-headers.sh, that is to show
> > everything that drifted in one single block, at the start of the build.

> > 	So unless you have a strong objection to this, I'll continue
> > investigation about how do do it with tools/perf/check-headers.sh,
 
> I have no objection but currently it is (theoretically) possible to compile
> Intel PT decoding support into perf script and perf report for any
> architecture. i.e. decoding Intel PT from a perf.data file does not depend
> on the build architecture.

Right, being on the tools/arch/ will not preclude it from being built
and linked in the other arches, I'll make sure it continues being built
there as well.

Thanks!

- Arnaldo