linux-kernel - Re: [PATCH V2 2/6] perf: Add branch stack extension

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: <20230802215814.GH231007@hirez.programming.kicks-ass.net>
Date:   Wed, 2 Aug 2023 23:58:14 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     kan.liang@...ux.intel.com
Cc:     mingo@...hat.com, acme@...nel.org, linux-kernel@...r.kernel.org,
        mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        jolsa@...nel.org, namhyung@...nel.org, irogers@...gle.com,
        adrian.hunter@...el.com, ak@...ux.intel.com, eranian@...gle.com,
        alexey.v.bayduraev@...ux.intel.com, tinghao.zhang@...el.com,
        Sandipan Das <sandipan.das@....com>,
        Ravi Bangoria <ravi.bangoria@....com>,
        Athira Rajeev <atrajeev@...ux.vnet.ibm.com>
Subject: Re: [PATCH V2 2/6] perf: Add branch stack extension

On Mon, May 22, 2023 at 04:30:36AM -0700, kan.liang@...ux.intel.com wrote:
> From: Kan Liang <kan.liang@...ux.intel.com>
> 
> Currently, the extra information of a branch entry is stored in a u64
> space. With more and more information added, the space is running out.
> For example, the information of occurrences of events will be added for
> each branch.
> 
> Add an extension space to record the new information for each branch
> entry. The space is appended after the struct perf_branch_stack.
> 
> Add a bit in struct perf_branch_entry to indicate whether the extra
> information is included.
> 
> Reviewed-by: Andi Kleen <ak@...ux.intel.com>
> Signed-off-by: Kan Liang <kan.liang@...ux.intel.com>
> Cc: Sandipan Das <sandipan.das@....com>
> Cc: Ravi Bangoria <ravi.bangoria@....com>
> Cc: Athira Rajeev <atrajeev@...ux.vnet.ibm.com>
> ---
> 
> New patch
> - Introduce a generic extension space which can be used to
>   store the LBR event information for Intel. It can also be used by
>   other ARCHs for the other purpose.
> - Add a new bit in struct perf_branch_entry to indicate whether the
>   extra information is included.

Bah.. I don't like this, also the actual format isn't clear to me.

The uapi part is severely lacking, it just adds the ext:1 thing, but
doesn't describe what if anything happens when it's set.

The internal perf_branch_stack_ext thing is just that, internal.
Additionally it contains a nr member, which seems to suggest it can be
different from the number of entries in the branch-stack itself -- which
would be odd indeed.

So we have an 'ext' bit per branch entry to indicate the existance of
this extra data, this again suggests no 1:1 correspondence, but at most
one extra entry per set bit.

Parsing this will be pretty horrible, no?

So what we have now is:

	{ u64			nr;
	  { u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
	  { u64 from, to, flags; } lbr[nr];
	} && PERF_SAMPLE_BRANCH_STACK

and AFAICT you're doing:

	{ u64			nr;
	  { u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
	  { u64 from, to, flags; } lbr[nr];
+	  { u64	nr2;
+	    { u64 extra; } extra[nr2];
+         } && OR_i{lbr[i].flags.ext}
	} && PERF_SAMPLE_BRANCH_STACK

Which is pretty horrific, no? The straight forward:

	{ u64			nr;
	  { u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
	  { u64 from, to, flags; } lbr[nr];
+	  { u64 extra; } ext[nr] && SOMETHING
	} && PERF_SAMPLE_BRANCH_STACK

Or perhaps even:

	{ u64			nr;
	  { u64 hw_idx; } && PERF_SAMPLE_BRANCH_HW_INDEX
	  { u64 from, to, flags; 
+	    u64 extra; && SOMETHING
	  } lbr[nr];
	} && PERF_SAMPLE_BRANCH_STACK

With the obvious question what 'SOMETHING' should be. I suppose
PERF_SAMPLE_BRANCH_EXTRA was considered and discarded?

Implementing the last suggestion wouldn't even be too bad, since having
PERF_SAMPLE_BRANCH_EXTRA set, we know to allocate and cast the existing
perf_sample_data::br_stack to a convenient new type, something like:

struct perf_branch_entry_ext {
	__u64	from;
	__u64	to;
	__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 */
		spec:2,     /* branch speculation info */
		new_type:4, /* additional branch type */
		priv:3,     /* privilege level */
		reserved:31;
	__u64	extra;
};

Except at that point I think I would suggest doing s/EXTRA/COUNTERS/g
and making it something like:

	union {
		__u64	counters;
		__u8 	c[8];
	};

Or something daft like that.

Wouldn't all that make *MUCH* more sense?