linux-kernel - Re: [PATCH 5/9] perf: Adding sysfs group format attribute for pmu device

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: <1328103384.2760.37.camel@laptop>
Date:	Wed, 01 Feb 2012 14:36:24 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Corey Ashford <cjashfor@...ux.vnet.ibm.com>
Cc:	Jiri Olsa <jolsa@...hat.com>, acme@...hat.com, mingo@...e.hu,
	paulus@...ba.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 5/9] perf: Adding sysfs group format attribute for pmu
 device

On Tue, 2012-01-31 at 17:25 -0800, Corey Ashford wrote:
> 
> One other comment that occurs to me is that it would be nice for perf to
> know when a supplied value is out of range, or will have undefined
> results.  For example, a field may be 8 bits wide, but not all 8-bit
> values are legal.  For example, there may be 208 events, and the codes
> may be somehwhat or even very sparsely encoded.  So, ideally, a config
> field in sysfs might look like this:
> 
> config1:0-7:0x0-0xd8,0xdb-0xe2,0xe4-0xe6
> 
> This way perf could check for valid values before stuffing them into
> registers, and give a good error message to the user.  If there is no
> restriction field, it would be assumed all of the possible values are valid.
> 
> I think the kernel code needs to check for bad values as well, because
> people can bypass the restrictions exposed by sysfs and use the
> perf_events API directly. 

Define bad? The only case where perf cares (from a kernel pov) is when
it can make the hardware melt and similar things. Programming the PMU in
a non-nonsensical but non-destructive way is fine, you get what you ask
for.



--
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/