All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Righi <arighi@nvidia.com>
To: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Martin KaFai Lau <martin.lau@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>, Tejun Heo <tj@kernel.org>,
	kkd@meta.com, kernel-team@meta.com
Subject: Re: [PATCH bpf-next v1 2/3] bpf: Add support for KF_RET_RCU flag
Date: Mon, 15 Sep 2025 08:14:18 +0200	[thread overview]
Message-ID: <aMeuunTYM8c6jp1m@gpd4> (raw)
In-Reply-To: <20250915024731.1494251-3-memxor@gmail.com>

Hi Kumar,

thanks for looking at this! Comment below.

On Mon, Sep 15, 2025 at 02:47:30AM +0000, Kumar Kartikeya Dwivedi wrote:
> Add a kfunc annotation 'KF_RET_RCU' to signal that the return type must
> be marked MEM_RCU, to return objects that are RCU protected. Naturally,
> this must imply that the kfunc is invoked in an RCU critical section,
> and thus the presence of this flag implies the presence of the
> KF_RCU_PROTECTED flag. Upcoming kfunc scx_bpf_cpu_curr() [0] will be
> made to make use of this flag.

I'm not sure we actually need two separate annotations, I can't think of a
case where KF_RCU_PROTECTED would be useful without also having KF_RET_RCU.

What I mean is: if the kfunc is only meant to be called inside an RCU
critical section, but doesn't return an RCU-protected pointer, then we can
simply add rcu_read_lock/unlock() internally in the kfunc. And for kfuncs
that take RCU-protected arguments we already have KF_RCU.

So it seems sufficient to have a single annotation that implements the
semantic "this kfunc returns an RCU-protected pointer".

What do you think?

Thanks,
-Andrea

> 
>   [0]: https://lore.kernel.org/all/20250903212311.369697-3-christian.loehle@arm.com
> 
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
>  Documentation/bpf/kfuncs.rst | 13 +++++++++++--
>  include/linux/btf.h          |  1 +
>  kernel/bpf/verifier.c        |  7 +++++++
>  3 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/bpf/kfuncs.rst b/Documentation/bpf/kfuncs.rst
> index 18ba1f7c26b3..7d1b7009338b 100644
> --- a/Documentation/bpf/kfuncs.rst
> +++ b/Documentation/bpf/kfuncs.rst
> @@ -346,10 +346,19 @@ arguments are at least RCU protected pointers. This may transitively imply that
>  RCU protection is ensured, but it does not work in cases of kfuncs which require
>  RCU protection but do not take RCU protected arguments.
>  
> +2.4.9 KF_RET_RCU flag
> +---------------------
> +
> +The KF_RET_RCU flag is used for kfuncs which return pointers to RCU protected
> +objects. Since this only works when the invocation of the kfunc is made in an
> +active RCU critical section, the usage of this flag implies ``KF_RCU_PROTECTED``
> +flag automatically. This flag may be combined with other return value modifiers,
> +such as ``KF_RET_NULL``.
> +
>  .. _KF_deprecated_flag:
>  
> -2.4.9 KF_DEPRECATED flag
> -------------------------
> +2.4.10 KF_DEPRECATED flag
> +-------------------------
>  
>  The KF_DEPRECATED flag is used for kfuncs which are scheduled to be
>  changed or removed in a subsequent kernel release. A kfunc that is
> diff --git a/include/linux/btf.h b/include/linux/btf.h
> index 9eda6b113f9b..97205b8a938c 100644
> --- a/include/linux/btf.h
> +++ b/include/linux/btf.h
> @@ -79,6 +79,7 @@
>  #define KF_ARENA_RET    (1 << 13) /* kfunc returns an arena pointer */
>  #define KF_ARENA_ARG1   (1 << 14) /* kfunc takes an arena pointer as its first argument */
>  #define KF_ARENA_ARG2   (1 << 15) /* kfunc takes an arena pointer as its second argument */
> +#define KF_RET_RCU      ((1 << 16) | KF_RCU_PROTECTED) /* kfunc returns an RCU protected pointer, implies KF_RCU_PROTECTED */
>  
>  /*
>   * Tag marking a kernel function as a kfunc. This is meant to minimize the
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index aa7c82ab50b9..f1cc602ed556 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -12342,6 +12342,11 @@ static bool is_kfunc_ret_null(struct bpf_kfunc_call_arg_meta *meta)
>  	return meta->kfunc_flags & KF_RET_NULL;
>  }
>  
> +static bool is_kfunc_ret_rcu(struct bpf_kfunc_call_arg_meta *meta)
> +{
> +	return meta->kfunc_flags & KF_RET_RCU;
> +}
> +
>  static bool is_kfunc_bpf_rcu_read_lock(struct bpf_kfunc_call_arg_meta *meta)
>  {
>  	return meta->func_id == special_kfunc_list[KF_bpf_rcu_read_lock];
> @@ -14042,6 +14047,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_ret_rcu(&meta))
> +				regs[BPF_REG_0].type |= MEM_RCU;
>  
>  			if (is_iter_next_kfunc(&meta)) {
>  				struct bpf_reg_state *cur_iter;
> -- 
> 2.51.0
> 

  reply	other threads:[~2025-09-15  6:14 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-09-15  2:47 [PATCH bpf-next v1 0/3] Update KF_RCU_PROTECTED, add KF_RET_RCU Kumar Kartikeya Dwivedi
2025-09-15  2:47 ` [PATCH bpf-next v1 1/3] bpf: Enforce RCU protection for KF_RCU_PROTECTED Kumar Kartikeya Dwivedi
2025-09-15  2:47 ` [PATCH bpf-next v1 2/3] bpf: Add support for KF_RET_RCU flag Kumar Kartikeya Dwivedi
2025-09-15  6:14   ` Andrea Righi [this message]
2025-09-15  7:13     ` Kumar Kartikeya Dwivedi
2025-09-15  8:02       ` Andrea Righi
2025-09-15 17:55         ` Alexei Starovoitov
2025-09-17  2:18           ` Kumar Kartikeya Dwivedi
2025-09-15  2:47 ` [PATCH bpf-next v1 3/3] selftests/bpf: Add tests for KF_RET_RCU Kumar Kartikeya Dwivedi
2025-09-15 12:20 ` [PATCH bpf-next v1 0/3] Update KF_RCU_PROTECTED, add KF_RET_RCU Andrea Righi

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=aMeuunTYM8c6jp1m@gpd4 \
    --to=arighi@nvidia.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --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.