All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduard Zingerman <eddyz87@gmail.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>, bpf@vger.kernel.org
Cc: Andrea Righi <arighi@nvidia.com>,
	Alexei Starovoitov <ast@kernel.org>,
	 Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau	 <martin.lau@kernel.org>,
	Tejun Heo <tj@kernel.org>,
	kkd@meta.com, 	kernel-team@meta.com
Subject: Re: [PATCH bpf-next v3 1/2] bpf: Enforce RCU protection for KF_RCU_PROTECTED
Date: Thu, 18 Sep 2025 14:00:20 -0700	[thread overview]
Message-ID: <412f49fa12de7c7f5d0461b56fd4e0b6882fa0ad.camel@gmail.com> (raw)
In-Reply-To: <20250917032755.4068726-2-memxor@gmail.com>

On Wed, 2025-09-17 at 03:27 +0000, Kumar Kartikeya Dwivedi wrote:
> Currently, KF_RCU_PROTECTED only applies to iterator APIs and that too
> in a convoluted fashion: the presence of this flag on the kfunc is used
> to set MEM_RCU in iterator type, and the lack of RCU protection results
> in an error only later, once next() or destroy() methods are invoked on
> the iterator. While there is no bug, this is certainly a bit
> unintuitive, and makes the enforcement of the flag iterator specific.
> 
> In the interest of making this flag useful for other upcoming kfuncs,
> e.g. scx_bpf_cpu_curr() [0][1], add enforcement for invoking the kfunc
> in an RCU critical section in general.
> 
> This would also mean that iterator APIs using KF_RCU_PROTECTED will
> error out earlier, instead of throwing an error for lack of RCU CS
> protection when next() or destroy() methods are invoked.
> 
> In addition to this, if the kfuncs tagged KF_RCU_PROTECTED return a
> pointer value, ensure that this pointer value is only usable in an RCU
> critical section. There might be edge cases where the return value is
> special and doesn't need to imply MEM_RCU semantics, but in general, the
> assumption should hold for the majority of kfuncs, and we can revisit
> things if necessary later.
> 
>   [0]: https://lore.kernel.org/all/20250903212311.369697-3-christian.loehle@arm.com
>   [1]: https://lore.kernel.org/all/20250909195709.92669-1-arighi@nvidia.com
> 
> Tested-by: Andrea Righi <arighi@nvidia.com>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]

> @@ -14037,6 +14045,8 @@ static int check_kfunc_call(struct bpf_verifier_env *env, struct bpf_insn *insn,
>  
>  			if (meta.func_id == special_kfunc_list[KF_bpf_get_kmem_cache])
>  				regs[BPF_REG_0].type |= PTR_UNTRUSTED;
> +			else if (is_kfunc_rcu_protected(&meta))
> +				regs[BPF_REG_0].type |= MEM_RCU;
>  
>  			if (is_iter_next_kfunc(&meta)) {
>  				struct bpf_reg_state *cur_iter;

The code below this hunk looks as follows:

			if (is_iter_next_kfunc(&meta)) {
				struct bpf_reg_state *cur_iter;

				cur_iter = get_iter_from_state(env->cur_state, &meta);

				if (cur_iter->type & MEM_RCU) /* KF_RCU_PROTECTED */
					regs[BPF_REG_0].type |= MEM_RCU;
				else
					regs[BPF_REG_0].type |= PTR_TRUSTED;
			}

Do we want to reduce it to:

			if (meta.func_id == special_kfunc_list[KF_bpf_get_kmem_cache])
				regs[BPF_REG_0].type |= PTR_UNTRUSTED;
			else if (is_kfunc_rcu_protected(&meta))
				regs[BPF_REG_0].type |= MEM_RCU;
			else if (is_iter_next_kfunc(&meta))
				regs[BPF_REG_0].type |= PTR_TRUSTED;

And mark relevant iterator next (and destroy?) functions as KF_RCU_PROTECTED?
(bpf_iter_css_next, bpf_iter_task_next, bpf_iter_scx_dsq_next).

I ask, because setting |= MEM_RCU in two places of this if branch
looks a bit iffy.

[...]

  reply	other threads:[~2025-09-18 21:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-17  3:27 [PATCH bpf-next v3 0/2] Update KF_RCU_PROTECTED Kumar Kartikeya Dwivedi
2025-09-17  3:27 ` [PATCH bpf-next v3 1/2] bpf: Enforce RCU protection for KF_RCU_PROTECTED Kumar Kartikeya Dwivedi
2025-09-18 21:00   ` Eduard Zingerman [this message]
2025-09-18 21:37     ` Kumar Kartikeya Dwivedi
2025-09-18 21:47       ` Eduard Zingerman
2025-09-18 21:59         ` Kumar Kartikeya Dwivedi
2025-09-18 22:02           ` Eduard Zingerman
2025-09-17  3:27 ` [PATCH bpf-next v3 2/2] selftests/bpf: Add tests " Kumar Kartikeya Dwivedi
2025-09-18 21:34   ` Eduard Zingerman
2025-09-17  8:27 ` [PATCH bpf-next v3 0/2] Update KF_RCU_PROTECTED Andrea Righi
2025-09-17  8:42   ` Kumar Kartikeya Dwivedi
2025-09-18 22:40 ` patchwork-bot+netdevbpf

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=412f49fa12de7c7f5d0461b56fd4e0b6882fa0ad.camel@gmail.com \
    --to=eddyz87@gmail.com \
    --cc=andrii@kernel.org \
    --cc=arighi@nvidia.com \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@meta.com \
    --cc=kkd@meta.com \
    --cc=martin.lau@kernel.org \
    --cc=memxor@gmail.com \
    --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.