Re: [PATCH RESEND sched_ext/for-7.2] sched_ext: Use offsetofend on both sides of the ops_cid layout assert

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The modified BUILD_BUG_ON assertion is tautological and no longer enforces the requirement that sched_ext_ops_cid ends exactly at @priv.
--

commit 5445ec05ee0d3c461f6dab131ab56481c5c2fc81
Author: Tejun Heo <tj@kernel.org>

sched_ext: Use offsetofend on both sides of the ops_cid layout assert

This commit modifies the layout assertion for sched_ext_ops_cid to use
offsetofend() instead of sizeof(). This change was made to avoid build
failures caused by trailing struct padding on 32-bit PPC architectures.

Closes: https://lore.kernel.org/oe-kbuild-all/202605081637.DbH4SZ1E-lkp@intel.com/
Fixes: 7e655ed7b953 ("sched_ext: Add bpf_sched_ext_ops_cid struct_ops type")

> diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
> index 1d7f206941f0c..5eece6c95cf5a 100644
> --- a/kernel/sched/ext.c
> +++ b/kernel/sched/ext.c
> @@ -10451,9 +10451,11 @@ static int __init scx_init(void)
>  	/*
>  	 * cid-form must end exactly at @priv - validate_ops() skips
>  	 * cpu_acquire/cpu_release for cid-form because reading those fields
> -	 * past the BPF allocation would be UB.
> +	 * past the BPF allocation would be UB. offsetofend() on both sides
> +	 * instead of sizeof() on sched_ext_ops_cid to sidestep trailing
> +	 * struct padding (e.g. 32-bit PPC tail-pads ops_cid past @priv).
>  	 */
> -	BUILD_BUG_ON(sizeof(struct sched_ext_ops_cid) !=
> +	BUILD_BUG_ON(offsetofend(struct sched_ext_ops_cid, priv) !=
>  		     offsetofend(struct sched_ext_ops, priv));

Does this modification inadvertently make the assertion a tautology?

The preceding CID_OFFSET_MATCH(priv, priv) already enforces that the offset
of the priv field is identical in both structures. Because offsetofend()
is defined as offsetof() plus sizeof_field(), and the type of priv is the
same in both structures, this BUILD_BUG_ON() check will always evaluate
to false.

If a new field were accidentally added to sched_ext_ops_cid after priv,
would this check fail to catch it since it no longer evaluates the overall
size of the structure?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260508160651.4030241-1-tj@kernel.org?part=1