All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Tejun Heo" <tj@kernel.org>
Cc: sched-ext@lists.linux.dev
Subject: Re: [PATCH sched_ext/for-7.3-fixes] sched_ext: Add a size argument to scx_bpf_cid_topo() so struct scx_cid_topo can grow
Date: Sat, 26 Sep 2026 19:34:37 +0000	[thread overview]
Message-ID: <20260926193438.38CFF1F000FF@smtp.kernel.org> (raw)
In-Reply-To: <fa6479d36b528573565ca22914451317@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpf: scx_bpf_cid_topo() requires unnecessary buffer initialization
--

commit 20cb7828d17e22cbc3ce2d88fade05994d50f729
Author: Tejun Heo <tj@kernel.org>

sched_ext: Add a size argument to scx_bpf_cid_topo() so struct scx_cid_topo can grow

This commit adds a size argument to the scx_bpf_cid_topo() kfunc to allow
the struct scx_cid_topo layout to grow over time. The kernel copies the
smaller of the provided buffer size and the kernel's struct size, setting
the remainder to -1.

> diff --git a/kernel/sched/ext/cid.c b/kernel/sched/ext/cid.c
> index bc4eee5bb4cbf..4b08866d75f6a 100644
> --- a/kernel/sched/ext/cid.c
> +++ b/kernel/sched/ext/cid.c
[ ... ]
> @@ -912,30 +912,36 @@ bool scx_cmask_empty(const struct scx_cmask *m)
>  /**
>   * scx_bpf_cid_topo - Copy out per-cid topology info
>   * @cid: cid to look up
> - * @out__uninit: where to copy the topology info; fully written by this call
> + * @out: where to copy the topology info
> + * @out__sz: size of @out, the program's sizeof(struct scx_cid_topo)
>   * @aux: implicit BPF argument to access bpf_prog_aux hidden from BPF progs
>   *
> - * Fill @out__uninit with the topology info for @cid. Trigger scx_error() if
> - * @cid is out of range. If @cid is valid but in the no-topo section, all fields
> - * are set to -1. All fields are also set to -1 when no cid tables have been
> - * published yet, which a program may observe while racing the root enable.
> + * Fill @out with the topology info for @cid. Trigger scx_error() if @cid is out
> + * of range. If @cid is valid but in the no-topo section, all fields are set to
> + * -1. All fields are also set to -1 when no cid tables have been published yet,
> + * which a program may observe while racing the root enable.
> + *
> + * The program's struct may be older or newer than the kernel's. The smaller of
> + * @out__sz and the kernel's size is copied and the rest of @out is set to -1.
>   */
> -__bpf_kfunc void scx_bpf_cid_topo(s32 cid, struct scx_cid_topo *out__uninit,
> +__bpf_kfunc void scx_bpf_cid_topo(s32 cid, struct scx_cid_topo *out, size_t out__sz,
>  				  const struct bpf_prog_aux *aux)

[Severity: Medium]
Will dropping the __uninit suffix from the out parameter force BPF
programs to initialize the struct scx_cid_topo buffer before calling
this kfunc?

Since the function fully overwrites the buffer via memset() and memcpy(),
forcing BPF programs to pre-initialize the memory creates unnecessary
overhead, as the verifier will reject uninitialized stack memory without
the MEM_UNINIT flag (which is applied when using the __uninit suffix).

The verifier should be able to map the size parameter based on the __sz
suffix regardless of the memory buffer's name (similar to existing kfuncs
like bpf_kfunc_test_uninit_mem(void *out__uninit, u32 out__sz)), so
out__uninit and out__sz can be used together safely.

>  {
> +	size_t len = min(out__sz, sizeof(*out));
>  	struct scx_cid_topo *topo;
>  	struct scx_sched *sch;
>  
> +	/* the error cases and fields the kernel lacks read as -1 */
> +	memset(out, 0xff, out__sz);
> +
>  	guard(rcu)();
>  
>  	sch = scx_prog_sched(aux);
>  	topo = rcu_dereference(scx_cid_topo);
> -	if (unlikely(!sch) || !cid_valid(sch, cid) || unlikely(!topo)) {
> -		*out__uninit = SCX_CID_TOPO_NEG;
> +	if (unlikely(!sch) || !cid_valid(sch, cid) || unlikely(!topo))
>  		return;
> -	}
>  
> -	*out__uninit = topo[cid];
> +	memcpy(out, &topo[cid], len);
>  }
>  
>  __bpf_kfunc_end_defs();

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

  reply	other threads:[~2026-09-26 19:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-26 19:23 [PATCH sched_ext/for-7.3-fixes] sched_ext: Add a size argument to scx_bpf_cid_topo() so struct scx_cid_topo can grow Tejun Heo
2026-09-26 19:34 ` sashiko-bot [this message]
2026-09-26 19:42 ` Andrea Righi
2026-09-26 20:15 ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260926193438.38CFF1F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=sched-ext@lists.linux.dev \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.