Re: [PATCH, v4] perf: Fix capabilities bitfield compatibility in'struct perf_event_mmap_page'

[Vince Weaver]

On Thu, 19 Sep 2013, Ingo Molnar wrote:

> To solve all that make this change explicit, detectable and self-contained,
> by iterating the ABI the following way:
> 
>  - Always clear bit 0, and rename it to usrpage->cap_bit0, to at least not
>    confuse old user-space binaries. RDPMC will be marked as unavailable
>    to old binaries but that's within the ABI, this is a capability bit.
> 
>  - Rename bit 1 to ->cap_bit0_is_deprecated and always set it to 1, so new
>    libraries can reliably detect that bit 0 is deprecated and perma-zero
>    without having to check the kernel version.
> 
>  - Use bits 2, 3, 4 for the newly defined, correct functionality:
> 
> 	cap_user_rdpmc		: 1, /* The RDPMC instruction can be used to read counts */
> 	cap_user_time		: 1, /* The time_* fields are used */
> 	cap_user_time_zero	: 1, /* The time_zero field is used */
> 

So let me think through the possible combinations:

OLD-KERNEL OLD-HEADER
   + cap_usr_rdpmc and cap_usr_time map to the same bit
   + In general for kernels from 3.4 to 3.11 the bit will be set
     for all x86

NEW-KERNEL OLD-HEADER
   + cap_usr_rdpmc (cap_bit0) and cap_usr_time (cap_bit0) both are 0
   + code detecting cap_usr_rdpmc will probably fall back to non-rdpmc
     even through rdpmc code is probably there and functioning

OLD-KERNEL NEW-HEADER
   + cap_user_rdpmc and cap_user_time both set to 0
   + cap_bit0_is_deprecated can be read; if it is 0 you can
     read cap_bit0, and if it is 1, assume rdpmc is available
     with the same likelyhood you could with the old header

NEW-KERNEL NEW-HEADER
   + Use cap_user_rdpmc and cap_user_time and everything is OK


>  - Rename all the bitfield names in perf_event.h to be different from the
>    old names, to make sure it's not possible to mis-compile it
>    accidentally with old assumptions.

Well this breaks that API, though I guess there are no guarantees there.
I guess that's intentional since it will force 
users to fix their code, but a pain if you aren't expecting it and 
suddenly your project doesn't compile anymore after a kernel-headers 
update.  Most of my code carries around its own perf_event.h so I guess
I'll be unaffected.

In any case this seems to be about as reasonable a solution to this 
problem as we can get.

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