From: Andrea Righi <arighi@nvidia.com>
To: Juntong Deng <juntong.deng@outlook.com>
Cc: ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
andrii@kernel.org, martin.lau@linux.dev, eddyz87@gmail.com,
song@kernel.org, yonghong.song@linux.dev, kpsingh@kernel.org,
sdf@fomichev.me, haoluo@google.com, jolsa@kernel.org,
memxor@gmail.com, tj@kernel.org, void@manifault.com,
changwoo@igalia.com, bpf@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next 2/8] sched_ext: Add filter for scx_kfunc_ids_select_cpu
Date: Fri, 7 Feb 2025 00:39:00 +0100 [thread overview]
Message-ID: <Z6VIFPucwML5YLSJ@gpd3> (raw)
In-Reply-To: <AM6PR03MB50805D6F4B8710EDB304CF5C99F72@AM6PR03MB5080.eurprd03.prod.outlook.com>
On Wed, Feb 05, 2025 at 07:30:14PM +0000, Juntong Deng wrote:
...
> +static int scx_kfunc_ids_other_rqlocked_filter(const struct bpf_prog *prog, u32 kfunc_id)
> +{
> + u32 moff = prog->aux->attach_st_ops_member_off;
> +
> + if (moff == offsetof(struct sched_ext_ops, runnable) ||
> + moff == offsetof(struct sched_ext_ops, dequeue) ||
> + moff == offsetof(struct sched_ext_ops, stopping) ||
> + moff == offsetof(struct sched_ext_ops, quiescent) ||
> + moff == offsetof(struct sched_ext_ops, yield) ||
> + moff == offsetof(struct sched_ext_ops, cpu_acquire) ||
> + moff == offsetof(struct sched_ext_ops, running) ||
> + moff == offsetof(struct sched_ext_ops, core_sched_before) ||
> + moff == offsetof(struct sched_ext_ops, set_cpumask) ||
> + moff == offsetof(struct sched_ext_ops, update_idle) ||
> + moff == offsetof(struct sched_ext_ops, tick) ||
> + moff == offsetof(struct sched_ext_ops, enable) ||
> + moff == offsetof(struct sched_ext_ops, set_weight) ||
> + moff == offsetof(struct sched_ext_ops, disable) ||
> + moff == offsetof(struct sched_ext_ops, exit_task) ||
> + moff == offsetof(struct sched_ext_ops, dump_task) ||
> + moff == offsetof(struct sched_ext_ops, dump_cpu))
> + return 0;
> +
> + return -EACCES;
Actually, do we need this filter at all?
I think the other filters in your patch set should be sufficient to
establish the correct permissions for all kfuncs, as none of them need to
be called from any rq-locked operations. Or am I missing something?
-Andrea
next prev parent reply other threads:[~2025-02-06 23:39 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 19:27 [RFC PATCH bpf-next 0/8] bpf, sched_ext: Make kfunc filters support struct_ops context to reduce runtime overhead Juntong Deng
2025-02-05 19:30 ` [RFC PATCH bpf-next 1/8] bpf: Add struct_ops context information to struct bpf_prog_aux Juntong Deng
2025-02-05 19:30 ` [RFC PATCH bpf-next 2/8] sched_ext: Add filter for scx_kfunc_ids_select_cpu Juntong Deng
2025-02-06 22:43 ` Andrea Righi
2025-02-06 23:39 ` Andrea Righi [this message]
2025-02-07 0:02 ` Juntong Deng
2025-02-05 19:30 ` [RFC PATCH bpf-next 3/8] sched_ext: Add filter for scx_kfunc_ids_enqueue_dispatch Juntong Deng
2025-02-05 19:30 ` [RFC PATCH bpf-next 4/8] sched_ext: Add filter for scx_kfunc_ids_dispatch Juntong Deng
2025-02-05 19:30 ` [RFC PATCH bpf-next 5/8] sched_ext: Add filter for scx_kfunc_ids_cpu_release Juntong Deng
2025-02-05 19:30 ` [RFC PATCH bpf-next 6/8] sched_ext: Add filter for scx_kfunc_ids_unlocked Juntong Deng
2025-02-08 3:37 ` Alexei Starovoitov
2025-02-09 15:22 ` Andrea Righi
2025-02-10 18:05 ` Tejun Heo
2025-02-10 23:40 ` Juntong Deng
2025-02-11 3:48 ` Alexei Starovoitov
2025-02-14 20:30 ` Juntong Deng
2025-02-05 19:30 ` [RFC PATCH bpf-next 7/8] sched_ext: Removed mask-based runtime restrictions on calling kfuncs in different contexts Juntong Deng
2025-02-05 19:30 ` [RFC PATCH bpf-next 8/8] selftests/sched_ext: Update enq_select_cpu_fails to adapt to struct_ops context filter Juntong Deng
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=Z6VIFPucwML5YLSJ@gpd3 \
--to=arighi@nvidia.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=changwoo@igalia.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=juntong.deng@outlook.com \
--cc=kpsingh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=sdf@fomichev.me \
--cc=song@kernel.org \
--cc=tj@kernel.org \
--cc=void@manifault.com \
--cc=yonghong.song@linux.dev \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®