Re: [PATCH v1 01/13] perf/core: add union to struct perf_branch_entry

From: Michael Ellerman <mpe@ellerman.id.au>
To: Stephane Eranian <eranian@google.com>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	linux-kernel@vger.kernel.org, acme@redhat.com, jolsa@redhat.com,
	kim.phillips@amd.com, namhyung@kernel.org, irogers@google.com,
	atrajeev@linux.vnet.ibm.com,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [PATCH v1 01/13] perf/core: add union to struct perf_branch_entry
Date: Fri, 17 Sep 2021 22:38:37 +1000	[thread overview]
Message-ID: <874kajjs1e.fsf@mpe.ellerman.id.au> (raw)
In-Reply-To: <CABPqkBRrx5vnPqTEnuQOeoJxyjiszCG7EMdK35ES=rHKYUNBpQ@mail.gmail.com>

Stephane Eranian <eranian@google.com> writes:
> Hi,
>
> On Fri, Sep 17, 2021 at 12:05 AM Michael Ellerman <mpe@ellerman.id.au> wrote:
>>
>> Stephane Eranian <eranian@google.com> writes:
>> > Hi,
>> >
>> > Thanks for fixing this in the perf tool. But what about the struct
>> > branch_entry in the header?
>>
>> I'm not sure what you mean.
>>
>> We can't change the order of the fields in the header, without breaking
>> existing userspace on BE systems.
>>
> Ok, I think I had missed that. You are saying that the
> #ifdef (__BIG_ENDIAN_BITFIELD) vs __LITTLE_ENDIAN_BITFIELD
>
> is only added to kernel-only data structures?

No, we *should* have used __BIG/LITTLE_ENDIAN_BITFIELD for the uapi
definition, but we forgot.

>> It's annoying that the bit numbers are different between LE & BE, but I
>> think it's too late to change that.
>>
> I agree.
>
>> So nothing should change in the branch_entry definition in the header.
>>
>> My comment on your patch was that adding the union with val, makes it
>> easier to misuse the bitfields, because now the values can be accessed
>> via the bitfields and also via val, but when using val you have to know
>> that the bit numbers differ between BE/LE.
>>
> Ok, I get it now. We do not need to expose val to user. This is added
> for kernel code convenience only.

Yeah. Putting the union with val in the uapi encourages userspace to
misuse val to bypass the bitfields, and that risks causing endian bugs.

> But if we keep it in kernel, that may break some other rules about
> uapi headers.

I don't follow what you mean there.

We could use #ifdef __KERNEL__ in the uapi header to make the union
kernel-only, see below, but it's pretty gross.

 struct perf_branch_entry {
	__u64	from;
	__u64	to;
 #ifdef __KERNEL__
	union {
		__u64	val;	    /* to make it easier to clear all fields */
		struct {
 #endif
			__u64	mispred:1,  /* target mispredicted */
				predicted:1,/* target predicted */
				in_tx:1,    /* in transaction */
				abort:1,    /* transaction abort */
				cycles:16,  /* cycle count to last branch */
				type:4,     /* branch type */
				reserved:40;
 #ifdef __KERNEL__
		};
	};
 #endif
 };

If we just do the inline I suggested we can clear the flags in a single
source line, and the generated code seems fine too, eg:

static inline void clear_perf_branch_entry_flags(struct perf_branch_entry *e)
{
	e->mispred = 0;
	e->predicted = 0;
	e->in_tx = 0;
	e->abort = 0;
	e->cycles = 0;
	e->type = 0;
	e->reserved = 0;
}

cheers