linux-kernel - Re: [tip: perf/core] perf trace: Introduce --filter for tracepoint events

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

Message-ID: <20191017131325.GB3437@redhat.com>
Date:   Thu, 17 Oct 2019 10:13:25 -0300
From:   Arnaldo Carvalho de Melo <acme@...hat.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     linux-tip-commits@...r.kernel.org,
        Adrian Hunter <adrian.hunter@...el.com>,
        Brendan Gregg <brendan.d.gregg@...il.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Luis Cláudio Gonçalves <lclaudio@...hat.com>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org
Subject: Re: [tip: perf/core] perf trace: Introduce --filter for tracepoint
 events

Em Thu, Oct 17, 2019 at 09:12:05AM +0200, Borislav Petkov escreveu:
> On Tue, Oct 15, 2019 at 05:31:43AM -0000, tip-bot2 for Arnaldo Carvalho de Melo wrote:
> > The following commit has been merged into the perf/core branch of tip:

> > Commit-ID:     d4097f1937f2242d0aa0a7c654d2159a6895e5c8
> > Gitweb:        https://git.kernel.org/tip/d4097f1937f2242d0aa0a7c654d2159a6895e5c8
> > Author:        Arnaldo Carvalho de Melo <acme@...hat.com>
> > AuthorDate:    Tue, 08 Oct 2019 07:33:08 -03:00
> > Committer:     Arnaldo Carvalho de Melo <acme@...hat.com>
> > CommitterDate: Wed, 09 Oct 2019 11:23:52 -03:00

> > perf trace: Introduce --filter for tracepoint events

> > Similar to what is in 'perf record', works just like there:

> >   # perf trace -e msr:*
> >    328.297 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.302 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.306 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.317 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.322 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.327 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.331 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.336 :0/0 msr:write_msr(msr: FS_BASE, val: 140240388381888)
> >    328.340 :0/0 ^Cmsr:write_msr(msr: FS_BASE, val: 140240388381888)
 
> I wonder if you guys can force this val:'s format to be always hex?
> Because MSR values are a lot more "natural" in hex...

Sure, I'll get there, for now its just setting scnprintf/strtoul helpers
based on tracepoint argument name and/or type.

But just like for syscalls, we'll get to have a way to specify that
'val', specifically for msr:write_msr, or sometimes, for the tracepoint
system part ('msr' in this case) should be formatted in some way.

For syscalls there is even provision for some args to be formmated based
on the value present in another arg, think ioctls, all this is being
refitted to support tracepoints other than the syscall ones.

The 'msr' one was the super low hanging fruit, we look just at its name,
no checks on what tracepoint it is, and we were investigating some stuff
at Red Hat and Marcelo said it was a PITA to be doing the lookups in
msr-index.h everytime he needed for look for those in traces, so came
first. :-)

- Arnaldo