linux-kernel - Re: [PATCH 3/4] perf tools: Add attr<num> syntax to event parser

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]

Date:	Fri, 7 Jun 2013 16:17:00 +0200
From:	Robert Richter <rric@...nel.org>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/4] perf tools: Add attr<num> syntax to event parser

On 03.06.13 15:54:22, Jiri Olsa wrote:
> On Fri, May 31, 2013 at 11:16:24AM +0200, Robert Richter wrote:
> > From: Robert Richter <robert.richter@...xeda.com>
> > 
> > The event parser is limited to update only a subset of all fields in
> > struct perf_event_attr (config*, period, branch_type). We are not able
> > to set other attr fields, esp. flags.
> > 
> > Introducing a new syntax to set any field of the event attribute by
> > using an index to the u64 value to be used within struct
> > perf_event_attr. The new syntax attr<num> is similar to config<num>,
> > but <num> specifies the index to be used. E.g. attr5:23 sets bit 23 of
> > the flag field of attr.
> > 
> > The persistent event implementation is a use case of the above. In
> > this case sysfs provides:
> > 
> >  /sys/bus/event_source/devices/persistent/events/mce_record:persistent,config=106
> >  /sys/bus/event_source/devices/persistent/format/persistent:attr5:23
> 
> good idea, you probably need to update:
> Documentation/ABI/testing/sysfs-bus-event_source-devices-format

I will add something there.

> also.. there's so far only mce_record event AFAICS, and this seems
> to be initialized at the time when sysfs's not ready so I dont get
> the sysfs entries for it.. and since there's no other event yet,
> the sysfs is not updated/populated later.. I think ;)

The code adds entries dynamically. If something was added to the
persistent events list, the sysfs entry is updated too. You should
actually should see something in sysfs. Code that registers it is here
for Intel or AMD:

 arch/x86/kernel/cpu/mcheck/mce.c:mcheck_init_tp()

> I'll probably tweak it somehow later, but if there was anything
> simple I could do or I missed something please let me know, that
> would speed up my testing

CONFIG_FTRACE should be enabled (which enables tracepoints), but this
is probably enabled per default. Otherwise the persistent pmu should
be visible in sysfs. What does dmesg show on your system?

-Robert
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/