Re: [PATCH][next] perf/x86: Avoid multiple -Wflex-array-member-not-at-end warnings

Re: [PATCH][next] perf/x86: Avoid multiple -Wflex-array-member-not-at-end warnings

[Gustavo A. R. Silva]

>    https://lore.kernel.org/all/20240806113254.GG12673@noisy.programming.kicks-ass.net/ 

Feel free to apply it.

Re: [PATCH][next] perf/x86: Avoid multiple -Wflex-array-member-not-at-end warnings

[Peter Zijlstra]

On Mon, May 04, 2026 at 01:50:50PM -0600, Gustavo A. R. Silva wrote:
> >    https://lore.kernel.org/all/20240806113254.GG12673@noisy.programming.kicks-ass.net/
> 
> Feel free to apply it.

Bah, stupid warning :/

There really is no sane way to tell the compiler that the code is fine
and it should just STFU already? I mean, it is directly followed by an
array of the right type to fill that flex thing.

Anyway, I suppose this all very much relies on the structure not getting
randomized, so let me stick __no_randomize_layout on it at the very
least.

Re: [PATCH][next] perf/x86: Avoid multiple -Wflex-array-member-not-at-end warnings

[Peter Zijlstra]

On Wed, Apr 29, 2026 at 01:29:18PM -0600, Gustavo A. R. Silva wrote:

> +	/*
> +	 * Intel LBR bits
> +	 */
> +	int				lbr_users;
> +	int				lbr_pebs_users;
> +	union {
> +		struct er_account		*lbr_sel;
> +		struct er_account		*lbr_ctl;
> +	};
> +	u64				br_sel;
> +	void				*last_task_ctx;
> +	int				last_log_id;
> +	int				lbr_select;
> +	void				*lbr_xsave;
> +
> +	/* Must be last as it ends in a flexible-array member. */
> +	TRAILING_OVERLAP(struct perf_branch_stack, lbr_stack, entries,
> +		struct perf_branch_entry	lbr_entries[MAX_LBR_ENTRIES];
> +		u64				lbr_counters[MAX_LBR_ENTRIES]; /* branch stack extra */
> +	);

FWIW, this thing is horrible crap. Per construction this thing does not
need to be last at all, you can have multiple such constructs in a
single structure and things would be perfectly fine.

Also, your TRAILING_OVERLAP() thing should probably have
__no_randomize_layout in ATTRS, rather than empty (and I'm assuming
__packed implies __no_randomized_layout, otherwise 'fun' things can
happen).

>  };

Re: [PATCH][next] perf/x86: Avoid multiple -Wflex-array-member-not-at-end warnings

[Peter Zijlstra]

On Thu, May 07, 2026 at 10:10:12AM +0200, Peter Zijlstra wrote:
> On Mon, May 04, 2026 at 01:50:50PM -0600, Gustavo A. R. Silva wrote:
> > >    https://lore.kernel.org/all/20240806113254.GG12673@noisy.programming.kicks-ass.net/
> > 
> > Feel free to apply it.
> 
> Bah, stupid warning :/
> 
> There really is no sane way to tell the compiler that the code is fine
> and it should just STFU already? I mean, it is directly followed by an
> array of the right type to fill that flex thing.
> 
> Anyway, I suppose this all very much relies on the structure not getting
> randomized, so let me stick __no_randomize_layout on it at the very
> least.

Ideally GCC would get fixed to allow something like so:

struct bar;

struct foo {
	...
	struct bar entries[];
};

struct ponies {
	...
	struct foo my_foo __sized_by(my_bars);
	struct bar my_bars[16];
	...
};

Such that the __sized_by() applies to foo::entries and ensures the
member is no longer considered unsized.

But I suspect this needs the whole of the flexarray insanity fixed;
because for some idiotic reason it is allowed for offsetof(struct foo,
entries) != sizeof(struct foo), and if that is the case, then everything
goes sideways in a hurry.

Note that the kernel very much does not rely on that weird behaviour,
since it always allocates sizeof(foo) + count * sizeof(foo::entries[0])
like. So we always have sufficient space at the end of the object.

And then I'm sure fixing flexarray is considered breaking ABI and so
we're left up a creek without no paddles on.

This is a giant shitshow, is what.