lkml.org 
[lkml]   [2013]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:perf/core] perf: Fix broken union in ' struct perf_event_mmap_page'
On Tue, Sep 17, 2013 at 04:23:25PM -0400, Vince Weaver wrote:
> > include/uapi/linux/perf_event.h | 8 +++++---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h
> > index 00d8274..0041aed 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -375,9 +375,11 @@ struct perf_event_mmap_page {
> > __u64 time_running; /* time event on cpu */
> > union {
> > __u64 capabilities;
> > - __u64 cap_usr_time : 1,
> > - cap_usr_rdpmc : 1,
> > - cap_____res : 62;
> > + struct {
> > + __u64 cap_usr_time : 1,
> > + cap_usr_rdpmc : 1,
> > + cap_____res : 62;
> > + };
> > };

> This patch somehow breaks the perf-ABI.

Difficult call that..

> If I take a program that reads "mmap->cap_usr_rdpmc" and compile it
> against the new header with this change (say from 3.12-rc1)
> and then run it on an old kernel (say 3.11) then I get "0" for
> cap_usr_rdpmc.
>
> If I take the same program and recompile against the old (without this
> patch) header and run it on 3.11, I get the expected "1" value.
>
> So something about this changed the bit pattern in an incompatible
> fashion.

Which was the entire point of the change. Previously cap_usr_time and
cap_usr_rdpmc were the same bit which clearly cannot be right.

With the change they're consecutive bits in the capabilities word.

Should we preserve completely broken things that don't work?


\
 
 \ /
  Last update: 2013-09-18 11:01    [W:0.131 / U:6.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site