[PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Kumar Kartikeya Dwivedi]

The kernel verifier recognizes __arena and __arena_nullable parameter
suffixes for registered kfuncs. These arguments need the matching
address_space(1) BTF type attribute so bpftool emits usable declarations.

Extend the existing KF_ARENA_ARG1/2 handling to select arguments by either
the legacy flag or either suffix. Iterate over all parameters, allowing the
suffix convention at any argument position and avoiding duplicate tags when
a flag and suffix select the same argument.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
 btf_encoder.c | 38 ++++++++++++++++++++++++++++----------
 dutil.h       | 13 +++++++++++++
 2 files changed, 41 insertions(+), 10 deletions(-)

diff --git a/btf_encoder.c b/btf_encoder.c
index 4b422e09800f..07ca4f41ac32 100644
--- a/btf_encoder.c
+++ b/btf_encoder.c
@@ -42,6 +42,8 @@
 #define BTF_KFUNC_TYPE_TAG	"bpf_kfunc"
 #define BTF_FASTCALL_TAG       "bpf_fastcall"
 #define BPF_ARENA_ATTR         "address_space(1)"
+#define BPF_ARENA_SUFFIX       "__arena"
+#define BPF_ARENA_NULLABLE_SUFFIX "__arena_nullable"
 
 /* kfunc flags, see include/linux/btf.h in the kernel source */
 #define KF_FASTCALL   (1 << 12)
@@ -808,12 +810,32 @@ static int btf__tag_bpf_arena_arg(struct btf *btf, struct btf_encoder_func_state
 	return id;
 }
 
-/* Modifies state->ret_type_id and state->parms[i].type_id for flagged kfuncs */
+static bool btf__is_bpf_arena_arg(const struct btf *btf,
+				  const struct btf_encoder_func_state *state, int idx)
+{
+	uint32_t flags = state->elf->kfunc_flags;
+	const char *name;
+	size_t name_len;
+
+	if ((idx == 0 && (flags & KF_ARENA_ARG1)) ||
+	    (idx == 1 && (flags & KF_ARENA_ARG2)))
+		return true;
+
+	name = btf__name_by_offset(btf, state->parms[idx].name_off);
+	if (!name)
+		return false;
+	name_len = strlen(name);
+	return (name_len > sizeof(BPF_ARENA_SUFFIX) - 1 && strends(name, BPF_ARENA_SUFFIX)) ||
+	       (name_len > sizeof(BPF_ARENA_NULLABLE_SUFFIX) - 1 &&
+		strends(name, BPF_ARENA_NULLABLE_SUFFIX));
+}
+
+/* Modifies state->ret_type_id and state->parms[i].type_id for arena kfuncs */
 static int btf__add_bpf_arena_type_tags(struct btf *btf, struct btf_encoder_func_state *state)
 {
 	uint32_t flags = state->elf->kfunc_flags;
 	int ret_type_id;
-	int err;
+	int err, i;
 
 	if (!btf__add_type_attr) {
 		fprintf(stderr, "btf__add_type_attr is not available, is libbpf < 1.6?\n");
@@ -830,14 +852,10 @@ static int btf__add_bpf_arena_type_tags(struct btf *btf, struct btf_encoder_func
 		state->ret_type_id = ret_type_id;
 	}
 
-	if (KF_ARENA_ARG1 & flags) {
-		err = btf__tag_bpf_arena_arg(btf, state, 0);
-		if (err < 0)
-			return err;
-	}
-
-	if (KF_ARENA_ARG2 & flags) {
-		err = btf__tag_bpf_arena_arg(btf, state, 1);
+	for (i = 0; i < state->nr_parms; i++) {
+		if (!btf__is_bpf_arena_arg(btf, state, i))
+			continue;
+		err = btf__tag_bpf_arena_arg(btf, state, i);
 		if (err < 0)
 			return err;
 	}
diff --git a/dutil.h b/dutil.h
index 603556fa0308..d55d01abc842 100644
--- a/dutil.h
+++ b/dutil.h
@@ -335,6 +335,19 @@ static inline bool strstarts(const char *str, const char *prefix)
 	return strncmp(str, prefix, strlen(prefix)) == 0;
 }
 
+/**
+ * strends - does @str end with @suffix?
+ * @str: string to examine
+ * @suffix: suffix to look for.
+ */
+static inline bool strends(const char *str, const char *suffix)
+{
+	size_t str_len = strlen(str);
+	size_t suffix_len = strlen(suffix);
+
+	return suffix_len <= str_len && strcmp(str + str_len - suffix_len, suffix) == 0;
+}
+
 void *zalloc(const size_t size);
 
 Elf_Scn *elf_section_by_name(Elf *elf, GElf_Shdr *shp, const char *name, size_t *index);
-- 
2.53.0

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Ihor Solodrai]

On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
> The kernel verifier recognizes __arena and __arena_nullable parameter
> suffixes for registered kfuncs. These arguments need the matching
> address_space(1) BTF type attribute so bpftool emits usable declarations.

Hi Kartikeya,

+cc: Emil, Tejun

This patch is certainly a no-go, because of the ongoing effort to move
decl/type tag BTF generation from pahole to resolve_btfids [1][2]. I'm
going to send the last unlanded bits of that soon.

*If* we decide to make this change, it shouldn't be done in pahole.

But even setting that aside:

> The kernel verifier recognizes __arena and __arena_nullable
> parameter suffixes for registered kfuncs.

This is not true. The only way the kernel can recognize an arena
argument is via one of the three kfunc flags: KF_ARENA_RET,
KF_ARENA_ARG1 and KF_ARENA_ARG2. No __arena suffix support exist:

  $ git log --oneline -n1
  7f333f85f83d (HEAD -> bpf-next, origin/for-next, origin/bpf-next, bpf-next/master, bpf-next/for-next, bpf-next/HEAD) Merge branch 'bpf-invalidate-rcu-pointers-after-final-spin-unlock'
  $ grep -r --include="*.[ch]" __arena  kernel/bpf/
    # ...nothing

__arena symbol is only used in sched_ext, libarena and selftests code
as an alias to __atrribute__((address_space(1))) or a type tag:

  $ grep -r --include="*.[ch]" 'define __arena '
  tools/sched_ext/include/scx/bpf_arena_common.bpf.h:#define __arena __attribute__((address_space(1)))
  tools/testing/selftests/bpf/libarena/include/bpf_arena_common.h:#define __arena __attribute__((address_space(1))) __attribute__((btf_type_tag("arena")))
  tools/testing/selftests/bpf/libarena/include/bpf_arena_common.h:#define __arena __attribute__((btf_type_tag("arena")))

AFAIR prior discussions that led to KF_ARENA_* flags implementation,
we decided to *not* add an __arena arg suffix support. We were talking
about getting rid of this suffix-annotation mechanism completely.

What we want long term is proper decl/type tags support from
compilers, so that in the kernel we could have and use:

  #define __arena __attribute__((btf_type_tag("arena")))

At the time KF_ARENA_* flags were introduced, this wasn't feasible
because GCC compiler didn't support the tags. I think it does since
recently, but even so we'll have to support older compiler builds for
quite a while.

So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
think we want to introduce and support yet another mechanism for arena
argument annotations. If we do, we'll be stuck with a mess of
supporting two/three ways of doing the same thing for the foreseeable future.

Maybe adding support for proper type-tagging is worthwhile long-term,
but not the name suffix.

[1] https://lore.kernel.org/bpf/20260601221805.821394-1-ihor.solodrai@linux.dev/
[2] https://lore.kernel.org/bpf/20260722233518.778854-1-ihor.solodrai@linux.dev/


> 
> Extend the existing KF_ARENA_ARG1/2 handling to select arguments by either
> the legacy flag or either suffix. Iterate over all parameters, allowing the
> suffix convention at any argument position and avoiding duplicate tags when
> a flag and suffix select the same argument.
> 
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---
>  btf_encoder.c | 38 ++++++++++++++++++++++++++++----------
>  dutil.h       | 13 +++++++++++++
>  2 files changed, 41 insertions(+), 10 deletions(-)
> 
> diff --git a/btf_encoder.c b/btf_encoder.c
> index 4b422e09800f..07ca4f41ac32 100644
> --- a/btf_encoder.c
> +++ b/btf_encoder.c
> @@ -42,6 +42,8 @@
>  #define BTF_KFUNC_TYPE_TAG	"bpf_kfunc"
>  #define BTF_FASTCALL_TAG       "bpf_fastcall"
>  #define BPF_ARENA_ATTR         "address_space(1)"
> +#define BPF_ARENA_SUFFIX       "__arena"
> +#define BPF_ARENA_NULLABLE_SUFFIX "__arena_nullable"
>  
>  /* kfunc flags, see include/linux/btf.h in the kernel source */
>  #define KF_FASTCALL   (1 << 12)
> @@ -808,12 +810,32 @@ static int btf__tag_bpf_arena_arg(struct btf *btf, struct btf_encoder_func_state
>  	return id;
>  }
>  
> -/* Modifies state->ret_type_id and state->parms[i].type_id for flagged kfuncs */
> +static bool btf__is_bpf_arena_arg(const struct btf *btf,
> +				  const struct btf_encoder_func_state *state, int idx)
> +{
> +	uint32_t flags = state->elf->kfunc_flags;
> +	const char *name;
> +	size_t name_len;
> +
> +	if ((idx == 0 && (flags & KF_ARENA_ARG1)) ||
> +	    (idx == 1 && (flags & KF_ARENA_ARG2)))
> +		return true;
> +
> +	name = btf__name_by_offset(btf, state->parms[idx].name_off);
> +	if (!name)
> +		return false;
> +	name_len = strlen(name);
> +	return (name_len > sizeof(BPF_ARENA_SUFFIX) - 1 && strends(name, BPF_ARENA_SUFFIX)) ||
> +	       (name_len > sizeof(BPF_ARENA_NULLABLE_SUFFIX) - 1 &&
> +		strends(name, BPF_ARENA_NULLABLE_SUFFIX));
> +}
> +
> +/* Modifies state->ret_type_id and state->parms[i].type_id for arena kfuncs */
>  static int btf__add_bpf_arena_type_tags(struct btf *btf, struct btf_encoder_func_state *state)
>  {
>  	uint32_t flags = state->elf->kfunc_flags;
>  	int ret_type_id;
> -	int err;
> +	int err, i;
>  
>  	if (!btf__add_type_attr) {
>  		fprintf(stderr, "btf__add_type_attr is not available, is libbpf < 1.6?\n");
> @@ -830,14 +852,10 @@ static int btf__add_bpf_arena_type_tags(struct btf *btf, struct btf_encoder_func
>  		state->ret_type_id = ret_type_id;
>  	}
>  
> -	if (KF_ARENA_ARG1 & flags) {
> -		err = btf__tag_bpf_arena_arg(btf, state, 0);
> -		if (err < 0)
> -			return err;
> -	}
> -
> -	if (KF_ARENA_ARG2 & flags) {
> -		err = btf__tag_bpf_arena_arg(btf, state, 1);
> +	for (i = 0; i < state->nr_parms; i++) {
> +		if (!btf__is_bpf_arena_arg(btf, state, i))
> +			continue;
> +		err = btf__tag_bpf_arena_arg(btf, state, i);
>  		if (err < 0)
>  			return err;
>  	}
> diff --git a/dutil.h b/dutil.h
> index 603556fa0308..d55d01abc842 100644
> --- a/dutil.h
> +++ b/dutil.h
> @@ -335,6 +335,19 @@ static inline bool strstarts(const char *str, const char *prefix)
>  	return strncmp(str, prefix, strlen(prefix)) == 0;
>  }
>  
> +/**
> + * strends - does @str end with @suffix?
> + * @str: string to examine
> + * @suffix: suffix to look for.
> + */
> +static inline bool strends(const char *str, const char *suffix)
> +{
> +	size_t str_len = strlen(str);
> +	size_t suffix_len = strlen(suffix);
> +
> +	return suffix_len <= str_len && strcmp(str + str_len - suffix_len, suffix) == 0;
> +}
> +
>  void *zalloc(const size_t size);
>  
>  Elf_Scn *elf_section_by_name(Elf *elf, GElf_Shdr *shp, const char *name, size_t *index);

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Kumar Kartikeya Dwivedi]

On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
> On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
>> The kernel verifier recognizes __arena and __arena_nullable parameter
>> suffixes for registered kfuncs. These arguments need the matching
>> address_space(1) BTF type attribute so bpftool emits usable declarations.
>
> Hi Kartikeya,
>
> +cc: Emil, Tejun
>
> This patch is certainly a no-go, because of the ongoing effort to move
> decl/type tag BTF generation from pahole to resolve_btfids [1][2]. I'm
> going to send the last unlanded bits of that soon.
>
> *If* we decide to make this change, it shouldn't be done in pahole.
>

Ah, I was unaware. Once you share those changes I'd be happy to rework this
support for resolve_btfids instead (i.e., tack it wherever we do
KF_ARENA_ARGS<N> handling right now).

> But even setting that aside:
>
>> The kernel verifier recognizes __arena and __arena_nullable
>> parameter suffixes for registered kfuncs.
>
> This is not true. The only way the kernel can recognize an arena
> argument is via one of the three kfunc flags: KF_ARENA_RET,
> KF_ARENA_ARG1 and KF_ARENA_ARG2. No __arena suffix support exist:
>
>   $ git log --oneline -n1
>   7f333f85f83d (HEAD -> bpf-next, origin/for-next, origin/bpf-next, bpf-next/master, bpf-next/for-next, bpf-next/HEAD) Merge branch 'bpf-invalidate-rcu-pointers-after-final-spin-unlock'
>   $ grep -r --include="*.[ch]" __arena  kernel/bpf/
>     # ...nothing
>

Yeah, I worded it poorly, I meant it was supposed to gain support for those
soon^TM, by way of the series here:
https://lore.kernel.org/bpf/20260803125115.2264733-1-memxor@gmail.com

> __arena symbol is only used in sched_ext, libarena and selftests code
> as an alias to __atrribute__((address_space(1))) or a type tag:
>
>   $ grep -r --include="*.[ch]" 'define __arena '
>   tools/sched_ext/include/scx/bpf_arena_common.bpf.h:#define __arena __attribute__((address_space(1)))
>   tools/testing/selftests/bpf/libarena/include/bpf_arena_common.h:#define __arena __attribute__((address_space(1))) __attribute__((btf_type_tag("arena")))
>   tools/testing/selftests/bpf/libarena/include/bpf_arena_common.h:#define __arena __attribute__((btf_type_tag("arena")))
>
> AFAIR prior discussions that led to KF_ARENA_* flags implementation,
> we decided to *not* add an __arena arg suffix support. We were talking
> about getting rid of this suffix-annotation mechanism completely.
>
> What we want long term is proper decl/type tags support from
> compilers, so that in the kernel we could have and use:
>
>   #define __arena __attribute__((btf_type_tag("arena")))
>
> At the time KF_ARENA_* flags were introduced, this wasn't feasible
> because GCC compiler didn't support the tags. I think it does since
> recently, but even so we'll have to support older compiler builds for
> quite a while.

I wasn't involved in the discussion for choosing the flag, so I do not remember
the nuance involved in making the choices back then. But please correct me or
provide context in case I do not capture something accurately below.

>
> So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
> think we want to introduce and support yet another mechanism for arena
> argument annotations. If we do, we'll be stuck with a mess of
> supporting two/three ways of doing the same thing for the foreseeable future.

I think one major difference is that KF_ARENA_ARG* things were mostly for
annotating the vmlinux.h with the right address space label before, but didn't
carry any semantic meaning for the kfunc's type checks.

That changes with these suffixes though. The pointer will be translated when
passed into the kfunc. IMO it would be odd to diverge for this particular case,
since we use suffixes for every other case where we constrain the input type of
the kfunc argument or give it special meaning.

We also want to have similar annotation on struct_ops callbacks, where we also
use suffixes, so it seemed better to keep it consistent.

I agree that all of these should be using type tags, but we're not there yet.

It is on my list of things to explore whether we can convert existing users of
KF_ARENA_ARG<N> flags (bpf_arena_alloc_pages(), etc.). We will have to modify
the implementation, and ensure we don't break compatibility by moving from
ignoring the type of input register to something we constrain to PTR_TO_ARENA
and SCALAR.

At that point, it should be possible to drop the kfunc flags, esp. if we are
worried about fragmenting ways of achieving the same thing (annotation of
vmlinux.h prototypes).

In functional terms, the only change on resolve_btfids side should be to use the
BTF parameter's emitted name for deciding whether it should trigger behavior
equivalent to the current KF_ARENA_ARG flags.

For better or worse, we need to be in this state of supporting suffixes until we
can declare bankruptcy of supporting GCC versions without type tags support.

> [...]

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Eduard Zingerman]

On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
> On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
> > On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
> > > The kernel verifier recognizes __arena and __arena_nullable parameter
> > > suffixes for registered kfuncs. These arguments need the matching
> > > address_space(1) BTF type attribute so bpftool emits usable declarations.
> > 
> > Hi Kartikeya,
> > 
> > +cc: Emil, Tejun
> > 
> > This patch is certainly a no-go, because of the ongoing effort to move
> > decl/type tag BTF generation from pahole to resolve_btfids [1][2]. I'm
> > going to send the last unlanded bits of that soon.
> > 
> > *If* we decide to make this change, it shouldn't be done in pahole.
> > 
> 
> Ah, I was unaware. Once you share those changes I'd be happy to rework this
> support for resolve_btfids instead (i.e., tack it wherever we do
> KF_ARENA_ARGS<N> handling right now).
> 
> > But even setting that aside:
> > 
> > > The kernel verifier recognizes __arena and __arena_nullable
> > > parameter suffixes for registered kfuncs.
> > 
> > This is not true. The only way the kernel can recognize an arena
> > argument is via one of the three kfunc flags: KF_ARENA_RET,
> > KF_ARENA_ARG1 and KF_ARENA_ARG2. No __arena suffix support exist:
> > 
> >   $ git log --oneline -n1
> >   7f333f85f83d (HEAD -> bpf-next, origin/for-next, origin/bpf-next, bpf-next/master, bpf-next/for-next, bpf-next/HEAD) Merge branch 'bpf-invalidate-rcu-pointers-after-final-spin-unlock'
> >   $ grep -r --include="*.[ch]" __arena  kernel/bpf/
> >     # ...nothing
> > 
> 
> Yeah, I worded it poorly, I meant it was supposed to gain support for those
> soon^TM, by way of the series here:
> https://lore.kernel.org/bpf/20260803125115.2264733-1-memxor@gmail.com
> 
> > __arena symbol is only used in sched_ext, libarena and selftests code
> > as an alias to __atrribute__((address_space(1))) or a type tag:
> > 
> >   $ grep -r --include="*.[ch]" 'define __arena '
> >   tools/sched_ext/include/scx/bpf_arena_common.bpf.h:#define __arena __attribute__((address_space(1)))
> >   tools/testing/selftests/bpf/libarena/include/bpf_arena_common.h:#define __arena __attribute__((address_space(1))) __attribute__((btf_type_tag("arena")))
> >   tools/testing/selftests/bpf/libarena/include/bpf_arena_common.h:#define __arena __attribute__((btf_type_tag("arena")))
> > 
> > AFAIR prior discussions that led to KF_ARENA_* flags implementation,
> > we decided to *not* add an __arena arg suffix support. We were talking
> > about getting rid of this suffix-annotation mechanism completely.
> > 
> > What we want long term is proper decl/type tags support from
> > compilers, so that in the kernel we could have and use:
> > 
> >   #define __arena __attribute__((btf_type_tag("arena")))
> > 
> > At the time KF_ARENA_* flags were introduced, this wasn't feasible
> > because GCC compiler didn't support the tags. I think it does since
> > recently, but even so we'll have to support older compiler builds for
> > quite a while.
> 
> I wasn't involved in the discussion for choosing the flag, so I do not remember
> the nuance involved in making the choices back then. But please correct me or
> provide context in case I do not capture something accurately below.
> 
> > 
> > So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
> > think we want to introduce and support yet another mechanism for arena
> > argument annotations. If we do, we'll be stuck with a mess of
> > supporting two/three ways of doing the same thing for the foreseeable future.
> 
> I think one major difference is that KF_ARENA_ARG* things were mostly for
> annotating the vmlinux.h with the right address space label before, but didn't
> carry any semantic meaning for the kfunc's type checks.
> 
> That changes with these suffixes though. The pointer will be translated when
> passed into the kfunc. IMO it would be odd to diverge for this particular case,
> since we use suffixes for every other case where we constrain the input type of
> the kfunc argument or give it special meaning.
> 
> We also want to have similar annotation on struct_ops callbacks, where we also
> use suffixes, so it seemed better to keep it consistent.

I agree that we should follow the principle of least surprise here and
use suffixes, as everything else uses suffixes as well.

And yes, the __arena and KF_ARENA_ARG* annotations have different
semantics:
- __arena means that user space arena address is passed as is
- KF_ARENA_ARG* means that a user space address is converted
  to a kernel space address before passing.

It appears, though, that from the BPF program side having an address
space annotation on the kfunc parameter would be helpful, as it avoids
an additional cast.

Tbh, it sounds like we want __arena_user and __arena_kern suffixes.

> I agree that all of these should be using type tags, but we're not there yet.

Let's put aside the type tags discussion for the time being.

...

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Ihor Solodrai]

On 8/4/26 1:22 PM, Eduard Zingerman wrote:
> On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
>> On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
>>> On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
>>>> [...]
>>
>>>
>>> So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
>>> think we want to introduce and support yet another mechanism for arena
>>> argument annotations. If we do, we'll be stuck with a mess of
>>> supporting two/three ways of doing the same thing for the foreseeable future.
>>
>> I think one major difference is that KF_ARENA_ARG* things were mostly for
>> annotating the vmlinux.h with the right address space label before, but didn't
>> carry any semantic meaning for the kfunc's type checks.
>>
>> That changes with these suffixes though. The pointer will be translated when
>> passed into the kfunc. IMO it would be odd to diverge for this particular case,
>> since we use suffixes for every other case where we constrain the input type of
>> the kfunc argument or give it special meaning.
>>
>> We also want to have similar annotation on struct_ops callbacks, where we also
>> use suffixes, so it seemed better to keep it consistent.
> 
> I agree that we should follow the principle of least surprise here and
> use suffixes, as everything else uses suffixes as well.

Ok, I understand the motivation. Let's say we use the suffixes.

Should this enable getting rid of KF_ARENA* flags then? For the
purposes of generating address_space(1), we can also just check the
name suffix, no?

> 
> And yes, the __arena and KF_ARENA_ARG* annotations have different
> semantics:
> - __arena means that user space arena address is passed as is
> - KF_ARENA_ARG* means that a user space address is converted
>   to a kernel space address before passing.

Also I am a little confused about whether we *need* to be able to
express two distinct meanings of "arena pointer" or not?

My understanding is that "arena pointer" is a feature of an arg type
that has a single meaning: the pointer has one base in BPF world, and
a different base when executed in the kernel.

The things that are missing is auto-conversion (Tejun's RFC [1]) and more
comprehensive support of PTR_TO_ARENA in the verifier.

This is still only one "arena" annotation per arg. Do we actually need
the proliferation of __arena, __arena__nullable and/or __arena_kern,
__arena_user? Can't we have a single defined semantics of how arena
pointers are supposed to work?

I can imagine something like follows:
  * arena pointers can not be null, check for nulls
    before passing from BPF prog to the kernel
  * arena pointers are converted to the kernel space for
    kfunc/struct_ops callback by the verifier

With the documented and enforced semantics like this one way of
annotating and one annotation should be enough.

What am I missing?

[1] https://lore.kernel.org/bpf/20260713024414.3759854-1-tj@kernel.org/

> 
> It appears, though, that from the BPF program side having an address
> space annotation on the kfunc parameter would be helpful, as it avoids
> an additional cast.
> > Tbh, it sounds like we want __arena_user and __arena_kern suffixes.
> 
>> I agree that all of these should be using type tags, but we're not there yet.
> 
> Let's put aside the type tags discussion for the time being.
> 
> ...

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Eduard Zingerman]

On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
> On 8/4/26 1:22 PM, Eduard Zingerman wrote:
> > On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
> > > On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
> > > > On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
> > > > > [...]
> > > 
> > > > 
> > > > So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
> > > > think we want to introduce and support yet another mechanism for arena
> > > > argument annotations. If we do, we'll be stuck with a mess of
> > > > supporting two/three ways of doing the same thing for the foreseeable future.
> > > 
> > > I think one major difference is that KF_ARENA_ARG* things were mostly for
> > > annotating the vmlinux.h with the right address space label before, but didn't
> > > carry any semantic meaning for the kfunc's type checks.
> > > 
> > > That changes with these suffixes though. The pointer will be translated when
> > > passed into the kfunc. IMO it would be odd to diverge for this particular case,
> > > since we use suffixes for every other case where we constrain the input type of
> > > the kfunc argument or give it special meaning.
> > > 
> > > We also want to have similar annotation on struct_ops callbacks, where we also
> > > use suffixes, so it seemed better to keep it consistent.
> > 
> > I agree that we should follow the principle of least surprise here and
> > use suffixes, as everything else uses suffixes as well.
> 
> Ok, I understand the motivation. Let's say we use the suffixes.
> 
> Should this enable getting rid of KF_ARENA* flags then? For the
> purposes of generating address_space(1), we can also just check the
> name suffix, no?

That would be ideal, yes.

> > 
> > And yes, the __arena and KF_ARENA_ARG* annotations have different
> > semantics:
> > - __arena means that user space arena address is passed as is
> > - KF_ARENA_ARG* means that a user space address is converted
> >   to a kernel space address before passing.
> 
> Also I am a little confused about whether we *need* to be able to
> express two distinct meanings of "arena pointer" or not?
> 
> My understanding is that "arena pointer" is a feature of an arg type
> that has a single meaning: the pointer has one base in BPF world, and
> a different base when executed in the kernel.
> 
> The things that are missing is auto-conversion (Tejun's RFC [1]) and more
> comprehensive support of PTR_TO_ARENA in the verifier.
> 
> This is still only one "arena" annotation per arg. Do we actually need
> the proliferation of __arena, __arena__nullable and/or __arena_kern,
> __arena_user? Can't we have a single defined semantics of how arena
> pointers are supposed to work?
> 
> I can imagine something like follows:
>   * arena pointers can not be null, check for nulls
>     before passing from BPF prog to the kernel

We are deliberately lax when handling arena and don't do any kind of
value tracking there. So e.g. the following won't work:

  if (foo->ptr) {
    ...
    kfunc(foo->ptr);
  }

Unless compiler decides to keep foo->ptr in a register. I'm not sure
whether enforcing non-null here from the verifier side is the right
call.

>   * arena pointers are converted to the kernel space for
>     kfunc/struct_ops callback by the verifier
> 
> With the documented and enforced semantics like this one way of
> annotating and one annotation should be enough.
> 
> What am I missing?

At the moment we have two consumers:
- Planned sched_ext related kfuncs that need kernel space pointers.
- Existing kfuncs with KF_ARENA_ARG:
  - bpf_arena_alloc_pages
  - bpf_arena_free_pages
  - bpf_arena_reserve_pages
  They, take a user space address. Looking at the code is appears that
  all three can be changed to handle kernel space address.
  On the other hand, neither of these *needs* the passed pointer to be
  converted to a kernel side arena pointer. So that would be just some
  useless work.

So there are two valid use cases.

...

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Kumar Kartikeya Dwivedi]

On Tue Aug 4, 2026 at 11:34 PM CEST, Eduard Zingerman wrote:
> On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
>> On 8/4/26 1:22 PM, Eduard Zingerman wrote:
>> > On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
>> > > On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
>> > > > On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
>> > > > > [...]
>> > >
>> > > >
>> > > > So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
>> > > > think we want to introduce and support yet another mechanism for arena
>> > > > argument annotations. If we do, we'll be stuck with a mess of
>> > > > supporting two/three ways of doing the same thing for the foreseeable future.
>> > >
>> > > I think one major difference is that KF_ARENA_ARG* things were mostly for
>> > > annotating the vmlinux.h with the right address space label before, but didn't
>> > > carry any semantic meaning for the kfunc's type checks.
>> > >
>> > > That changes with these suffixes though. The pointer will be translated when
>> > > passed into the kfunc. IMO it would be odd to diverge for this particular case,
>> > > since we use suffixes for every other case where we constrain the input type of
>> > > the kfunc argument or give it special meaning.
>> > >
>> > > We also want to have similar annotation on struct_ops callbacks, where we also
>> > > use suffixes, so it seemed better to keep it consistent.
>> >
>> > I agree that we should follow the principle of least surprise here and
>> > use suffixes, as everything else uses suffixes as well.
>>
>> Ok, I understand the motivation. Let's say we use the suffixes.
>>
>> Should this enable getting rid of KF_ARENA* flags then? For the
>> purposes of generating address_space(1), we can also just check the
>> name suffix, no?
>
> That would be ideal, yes.
>
>> >
>> > And yes, the __arena and KF_ARENA_ARG* annotations have different
>> > semantics:
>> > - __arena means that user space arena address is passed as is
>> > - KF_ARENA_ARG* means that a user space address is converted
>> >   to a kernel space address before passing.
>>
>> Also I am a little confused about whether we *need* to be able to
>> express two distinct meanings of "arena pointer" or not?
>>
>> My understanding is that "arena pointer" is a feature of an arg type
>> that has a single meaning: the pointer has one base in BPF world, and
>> a different base when executed in the kernel.
>>
>> The things that are missing is auto-conversion (Tejun's RFC [1]) and more
>> comprehensive support of PTR_TO_ARENA in the verifier.
>>
>> This is still only one "arena" annotation per arg. Do we actually need
>> the proliferation of __arena, __arena__nullable and/or __arena_kern,
>> __arena_user? Can't we have a single defined semantics of how arena
>> pointers are supposed to work?
>>
>> I can imagine something like follows:
>>   * arena pointers can not be null, check for nulls
>>     before passing from BPF prog to the kernel
>
> We are deliberately lax when handling arena and don't do any kind of
> value tracking there. So e.g. the following won't work:
>
>   if (foo->ptr) {
>     ...
>     kfunc(foo->ptr);
>   }
>
> Unless compiler decides to keep foo->ptr in a register. I'm not sure
> whether enforcing non-null here from the verifier side is the right
> call.
>
>>   * arena pointers are converted to the kernel space for
>>     kfunc/struct_ops callback by the verifier
>>
>> With the documented and enforced semantics like this one way of
>> annotating and one annotation should be enough.
>>
>> What am I missing?
>
> At the moment we have two consumers:
> - Planned sched_ext related kfuncs that need kernel space pointers.
> - Existing kfuncs with KF_ARENA_ARG:
>   - bpf_arena_alloc_pages
>   - bpf_arena_free_pages
>   - bpf_arena_reserve_pages
>   They, take a user space address. Looking at the code is appears that
>   all three can be changed to handle kernel space address.
>   On the other hand, neither of these *needs* the passed pointer to be
>   converted to a kernel side arena pointer. So that would be just some
>   useless work.

I don't think it's useless work, they translate manually because the actual page
table operations happen using the kernel address anyway. IMO they probably need
access to both, and having one gives other, but kaddr is more important for them
to actually carry out the page table manipulation.

>
> So there are two valid use cases.
>
> ...

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Eduard Zingerman]

On Tue, 2026-08-04 at 23:46 +0200, Kumar Kartikeya Dwivedi wrote:
> On Tue Aug 4, 2026 at 11:34 PM CEST, Eduard Zingerman wrote:
> > On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
> > > On 8/4/26 1:22 PM, Eduard Zingerman wrote:
> > > > On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
> > > > > On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
> > > > > > On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
> > > > > > > [...]
> > > > > 
> > > > > > 
> > > > > > So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
> > > > > > think we want to introduce and support yet another mechanism for arena
> > > > > > argument annotations. If we do, we'll be stuck with a mess of
> > > > > > supporting two/three ways of doing the same thing for the foreseeable future.
> > > > > 
> > > > > I think one major difference is that KF_ARENA_ARG* things were mostly for
> > > > > annotating the vmlinux.h with the right address space label before, but didn't
> > > > > carry any semantic meaning for the kfunc's type checks.
> > > > > 
> > > > > That changes with these suffixes though. The pointer will be translated when
> > > > > passed into the kfunc. IMO it would be odd to diverge for this particular case,
> > > > > since we use suffixes for every other case where we constrain the input type of
> > > > > the kfunc argument or give it special meaning.
> > > > > 
> > > > > We also want to have similar annotation on struct_ops callbacks, where we also
> > > > > use suffixes, so it seemed better to keep it consistent.
> > > > 
> > > > I agree that we should follow the principle of least surprise here and
> > > > use suffixes, as everything else uses suffixes as well.
> > > 
> > > Ok, I understand the motivation. Let's say we use the suffixes.
> > > 
> > > Should this enable getting rid of KF_ARENA* flags then? For the
> > > purposes of generating address_space(1), we can also just check the
> > > name suffix, no?
> > 
> > That would be ideal, yes.
> > 
> > > > 
> > > > And yes, the __arena and KF_ARENA_ARG* annotations have different
> > > > semantics:
> > > > - __arena means that user space arena address is passed as is
> > > > - KF_ARENA_ARG* means that a user space address is converted
> > > >   to a kernel space address before passing.
> > > 
> > > Also I am a little confused about whether we *need* to be able to
> > > express two distinct meanings of "arena pointer" or not?
> > > 
> > > My understanding is that "arena pointer" is a feature of an arg type
> > > that has a single meaning: the pointer has one base in BPF world, and
> > > a different base when executed in the kernel.
> > > 
> > > The things that are missing is auto-conversion (Tejun's RFC [1]) and more
> > > comprehensive support of PTR_TO_ARENA in the verifier.
> > > 
> > > This is still only one "arena" annotation per arg. Do we actually need
> > > the proliferation of __arena, __arena__nullable and/or __arena_kern,
> > > __arena_user? Can't we have a single defined semantics of how arena
> > > pointers are supposed to work?
> > > 
> > > I can imagine something like follows:
> > >   * arena pointers can not be null, check for nulls
> > >     before passing from BPF prog to the kernel
> > 
> > We are deliberately lax when handling arena and don't do any kind of
> > value tracking there. So e.g. the following won't work:
> > 
> >   if (foo->ptr) {
> >     ...
> >     kfunc(foo->ptr);
> >   }
> > 
> > Unless compiler decides to keep foo->ptr in a register. I'm not sure
> > whether enforcing non-null here from the verifier side is the right
> > call.
> > 
> > >   * arena pointers are converted to the kernel space for
> > >     kfunc/struct_ops callback by the verifier
> > > 
> > > With the documented and enforced semantics like this one way of
> > > annotating and one annotation should be enough.
> > > 
> > > What am I missing?
> > 
> > At the moment we have two consumers:
> > - Planned sched_ext related kfuncs that need kernel space pointers.
> > - Existing kfuncs with KF_ARENA_ARG:
> >   - bpf_arena_alloc_pages
> >   - bpf_arena_free_pages
> >   - bpf_arena_reserve_pages
> >   They, take a user space address. Looking at the code is appears that
> >   all three can be changed to handle kernel space address.
> >   On the other hand, neither of these *needs* the passed pointer to be
> >   converted to a kernel side arena pointer. So that would be just some
> >   useless work.
> 
> I don't think it's useless work, they translate manually because the actual page
> table operations happen using the kernel address anyway. IMO they probably need
> access to both, and having one gives other, but kaddr is more important for them
> to actually carry out the page table manipulation.

From what I see these function compute the page number by subtracting
user vm start from the pointer. So, if switched to a kernel pointer
that would uaddr -> kaddr -> (kaddr - start) / page_size.
Compared to current (uaddr - ustart) / page_size.
But we can live with that.

What's an overall conclusion? A single __arena suffix and modified
existing consumers? What would be the semantics for __nullable?

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Kumar Kartikeya Dwivedi]

On Tue Aug 4, 2026 at 11:51 PM CEST, Eduard Zingerman wrote:
> On Tue, 2026-08-04 at 23:46 +0200, Kumar Kartikeya Dwivedi wrote:
>> On Tue Aug 4, 2026 at 11:34 PM CEST, Eduard Zingerman wrote:
>> > On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
>> > > On 8/4/26 1:22 PM, Eduard Zingerman wrote:
>> > > > On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
>> > > > > On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
>> > > > > > On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
>> > > > > > > [...]
>> > > > >
>> > > > > >
>> > > > > > So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
>> > > > > > think we want to introduce and support yet another mechanism for arena
>> > > > > > argument annotations. If we do, we'll be stuck with a mess of
>> > > > > > supporting two/three ways of doing the same thing for the foreseeable future.
>> > > > >
>> > > > > I think one major difference is that KF_ARENA_ARG* things were mostly for
>> > > > > annotating the vmlinux.h with the right address space label before, but didn't
>> > > > > carry any semantic meaning for the kfunc's type checks.
>> > > > >
>> > > > > That changes with these suffixes though. The pointer will be translated when
>> > > > > passed into the kfunc. IMO it would be odd to diverge for this particular case,
>> > > > > since we use suffixes for every other case where we constrain the input type of
>> > > > > the kfunc argument or give it special meaning.
>> > > > >
>> > > > > We also want to have similar annotation on struct_ops callbacks, where we also
>> > > > > use suffixes, so it seemed better to keep it consistent.
>> > > >
>> > > > I agree that we should follow the principle of least surprise here and
>> > > > use suffixes, as everything else uses suffixes as well.
>> > >
>> > > Ok, I understand the motivation. Let's say we use the suffixes.
>> > >
>> > > Should this enable getting rid of KF_ARENA* flags then? For the
>> > > purposes of generating address_space(1), we can also just check the
>> > > name suffix, no?
>> >
>> > That would be ideal, yes.
>> >
>> > > >
>> > > > And yes, the __arena and KF_ARENA_ARG* annotations have different
>> > > > semantics:
>> > > > - __arena means that user space arena address is passed as is
>> > > > - KF_ARENA_ARG* means that a user space address is converted
>> > > >   to a kernel space address before passing.
>> > >
>> > > Also I am a little confused about whether we *need* to be able to
>> > > express two distinct meanings of "arena pointer" or not?
>> > >
>> > > My understanding is that "arena pointer" is a feature of an arg type
>> > > that has a single meaning: the pointer has one base in BPF world, and
>> > > a different base when executed in the kernel.
>> > >
>> > > The things that are missing is auto-conversion (Tejun's RFC [1]) and more
>> > > comprehensive support of PTR_TO_ARENA in the verifier.
>> > >
>> > > This is still only one "arena" annotation per arg. Do we actually need
>> > > the proliferation of __arena, __arena__nullable and/or __arena_kern,
>> > > __arena_user? Can't we have a single defined semantics of how arena
>> > > pointers are supposed to work?
>> > >
>> > > I can imagine something like follows:
>> > >   * arena pointers can not be null, check for nulls
>> > >     before passing from BPF prog to the kernel
>> >
>> > We are deliberately lax when handling arena and don't do any kind of
>> > value tracking there. So e.g. the following won't work:
>> >
>> >   if (foo->ptr) {
>> >     ...
>> >     kfunc(foo->ptr);
>> >   }
>> >
>> > Unless compiler decides to keep foo->ptr in a register. I'm not sure
>> > whether enforcing non-null here from the verifier side is the right
>> > call.
>> >
>> > >   * arena pointers are converted to the kernel space for
>> > >     kfunc/struct_ops callback by the verifier
>> > >
>> > > With the documented and enforced semantics like this one way of
>> > > annotating and one annotation should be enough.
>> > >
>> > > What am I missing?
>> >
>> > At the moment we have two consumers:
>> > - Planned sched_ext related kfuncs that need kernel space pointers.
>> > - Existing kfuncs with KF_ARENA_ARG:
>> >   - bpf_arena_alloc_pages
>> >   - bpf_arena_free_pages
>> >   - bpf_arena_reserve_pages
>> >   They, take a user space address. Looking at the code is appears that
>> >   all three can be changed to handle kernel space address.
>> >   On the other hand, neither of these *needs* the passed pointer to be
>> >   converted to a kernel side arena pointer. So that would be just some
>> >   useless work.
>>
>> I don't think it's useless work, they translate manually because the actual page
>> table operations happen using the kernel address anyway. IMO they probably need
>> access to both, and having one gives other, but kaddr is more important for them
>> to actually carry out the page table manipulation.
>
> From what I see these function compute the page number by subtracting
> user vm start from the pointer. So, if switched to a kernel pointer
> that would uaddr -> kaddr -> (kaddr - start) / page_size.
> Compared to current (uaddr - ustart) / page_size.
> But we can live with that.
>
> What's an overall conclusion? A single __arena suffix and modified
> existing consumers? What would be the semantics for __nullable?

It would just signify expectations for kernel consumers, but we shouldn't be
enforcing it in the verifier, since we'll inevitably have to track the state of
the arena pointer, which we shouldn't do.

It just degrades to pointer to first page when you break the expectation, which
should be reported as a fault through the BPF stream for the program (or aborts
the program on fault, if that ever materializes in the future).

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Ihor Solodrai]

On 8/4/26 2:51 PM, Eduard Zingerman wrote:
> On Tue, 2026-08-04 at 23:46 +0200, Kumar Kartikeya Dwivedi wrote:
>> On Tue Aug 4, 2026 at 11:34 PM CEST, Eduard Zingerman wrote:
>>> On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
>>>> On 8/4/26 1:22 PM, Eduard Zingerman wrote:
>>>> [...]
>>>> What am I missing?
>>>
>>> At the moment we have two consumers:
>>> - Planned sched_ext related kfuncs that need kernel space pointers.
>>> - Existing kfuncs with KF_ARENA_ARG:
>>>   - bpf_arena_alloc_pages
>>>   - bpf_arena_free_pages
>>>   - bpf_arena_reserve_pages
>>>   They, take a user space address. Looking at the code is appears that
>>>   all three can be changed to handle kernel space address.
>>>   On the other hand, neither of these *needs* the passed pointer to be
>>>   converted to a kernel side arena pointer. So that would be just some
>>>   useless work.
>>
>> I don't think it's useless work, they translate manually because the actual page
>> table operations happen using the kernel address anyway. IMO they probably need
>> access to both, and having one gives other, but kaddr is more important for them
>> to actually carry out the page table manipulation.
> 
> From what I see these function compute the page number by subtracting
> user vm start from the pointer. So, if switched to a kernel pointer
> that would uaddr -> kaddr -> (kaddr - start) / page_size.
> Compared to current (uaddr - ustart) / page_size.
> But we can live with that.
> 
> What's an overall conclusion? A single __arena suffix and modified
> existing consumers? What would be the semantics for __nullable?

Apparently, we also have btf_decl_tag("arg:arena") and a type tag.

So that's three different arena annotations already:
- decl tag for PTR_TO_ARENA for global funcs [1]
- type tags for BPF declarations [2]
- KF_ARENA_* flags to pass through the address_space(1)

and now we are adding __arena suffix for auto-rebasing

It's a mess, gentlemen.

Since the verifier already recognizes the type tags, shouldn't we
be using them?..

[1] https://lore.kernel.org/bpf/20240209040608.98927-11-alexei.starovoitov@gmail.com/
[2] https://lore.kernel.org/bpf/20260602004120.17087-1-emil@etsalapatis.com/

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Kumar Kartikeya Dwivedi]

On Wed Aug 5, 2026 at 12:57 AM CEST, Ihor Solodrai wrote:
> On 8/4/26 2:51 PM, Eduard Zingerman wrote:
>> On Tue, 2026-08-04 at 23:46 +0200, Kumar Kartikeya Dwivedi wrote:
>>> On Tue Aug 4, 2026 at 11:34 PM CEST, Eduard Zingerman wrote:
>>>> On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
>>>>> On 8/4/26 1:22 PM, Eduard Zingerman wrote:
>>>>> [...]
>>>>> What am I missing?
>>>>
>>>> At the moment we have two consumers:
>>>> - Planned sched_ext related kfuncs that need kernel space pointers.
>>>> - Existing kfuncs with KF_ARENA_ARG:
>>>>   - bpf_arena_alloc_pages
>>>>   - bpf_arena_free_pages
>>>>   - bpf_arena_reserve_pages
>>>>   They, take a user space address. Looking at the code is appears that
>>>>   all three can be changed to handle kernel space address.
>>>>   On the other hand, neither of these *needs* the passed pointer to be
>>>>   converted to a kernel side arena pointer. So that would be just some
>>>>   useless work.
>>>
>>> I don't think it's useless work, they translate manually because the actual page
>>> table operations happen using the kernel address anyway. IMO they probably need
>>> access to both, and having one gives other, but kaddr is more important for them
>>> to actually carry out the page table manipulation.
>>
>> From what I see these function compute the page number by subtracting
>> user vm start from the pointer. So, if switched to a kernel pointer
>> that would uaddr -> kaddr -> (kaddr - start) / page_size.
>> Compared to current (uaddr - ustart) / page_size.
>> But we can live with that.
>>
>> What's an overall conclusion? A single __arena suffix and modified
>> existing consumers? What would be the semantics for __nullable?
>
> Apparently, we also have btf_decl_tag("arg:arena") and a type tag.
>
> So that's three different arena annotations already:
> - decl tag for PTR_TO_ARENA for global funcs [1]
> - type tags for BPF declarations [2]

I think both serve different purposes. It makes sense for it to be type tag,
e.g. for it to be able to go into typedefs, etc. All suffixes we have on kernel
side will probably otherwise be declaration tags excluding other similar cases
to arena (like __rcu).

> - KF_ARENA_* flags to pass through the address_space(1)
>
> and now we are adding __arena suffix for auto-rebasing

This would be a type tag if we could do it that way, unfortunately since it gets
applied on the kernel side, we have to use a suffix. __arena tag used in program
BTF for kfunc or struct_ops is not authoritative, it needs to come from the
kernel.

>
> It's a mess, gentlemen.
>
> Since the verifier already recognizes the type tags, shouldn't we
> be using them?..
>
> [1] https://lore.kernel.org/bpf/20240209040608.98927-11-alexei.starovoitov@gmail.com/
> [2] https://lore.kernel.org/bpf/20260602004120.17087-1-emil@etsalapatis.com/

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Ihor Solodrai]

On 8/4/26 2:34 PM, Eduard Zingerman wrote:
> On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
>> On 8/4/26 1:22 PM, Eduard Zingerman wrote:
>>> On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
>>>> On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
>>>>> On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
>>>>>> [...]
>>>>
>>>>>
>>>>> So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
>>>>> think we want to introduce and support yet another mechanism for arena
>>>>> argument annotations. If we do, we'll be stuck with a mess of
>>>>> supporting two/three ways of doing the same thing for the foreseeable future.
>>>>
>>>> I think one major difference is that KF_ARENA_ARG* things were mostly for
>>>> annotating the vmlinux.h with the right address space label before, but didn't
>>>> carry any semantic meaning for the kfunc's type checks.
>>>>
>>>> That changes with these suffixes though. The pointer will be translated when
>>>> passed into the kfunc. IMO it would be odd to diverge for this particular case,
>>>> since we use suffixes for every other case where we constrain the input type of
>>>> the kfunc argument or give it special meaning.
>>>>
>>>> We also want to have similar annotation on struct_ops callbacks, where we also
>>>> use suffixes, so it seemed better to keep it consistent.
>>>
>>> I agree that we should follow the principle of least surprise here and
>>> use suffixes, as everything else uses suffixes as well.
>>
>> Ok, I understand the motivation. Let's say we use the suffixes.
>>
>> Should this enable getting rid of KF_ARENA* flags then? For the
>> purposes of generating address_space(1), we can also just check the
>> name suffix, no?
> 
> That would be ideal, yes.
> 
>>>
>>> And yes, the __arena and KF_ARENA_ARG* annotations have different
>>> semantics:
>>> - __arena means that user space arena address is passed as is
>>> - KF_ARENA_ARG* means that a user space address is converted
>>>   to a kernel space address before passing.
>>
>> Also I am a little confused about whether we *need* to be able to
>> express two distinct meanings of "arena pointer" or not?
>>
>> My understanding is that "arena pointer" is a feature of an arg type
>> that has a single meaning: the pointer has one base in BPF world, and
>> a different base when executed in the kernel.
>>
>> The things that are missing is auto-conversion (Tejun's RFC [1]) and more
>> comprehensive support of PTR_TO_ARENA in the verifier.
>>
>> This is still only one "arena" annotation per arg. Do we actually need
>> the proliferation of __arena, __arena__nullable and/or __arena_kern,
>> __arena_user? Can't we have a single defined semantics of how arena
>> pointers are supposed to work?
>>
>> I can imagine something like follows:
>>   * arena pointers can not be null, check for nulls
>>     before passing from BPF prog to the kernel
> 
> We are deliberately lax when handling arena and don't do any kind of
> value tracking there. So e.g. the following won't work:
> 
>   if (foo->ptr) {
>     ...
>     kfunc(foo->ptr);
>   }
> 
> Unless compiler decides to keep foo->ptr in a register. I'm not sure
> whether enforcing non-null here from the verifier side is the right
> call.

I don't argue for this particular semantics, it's just an example.

My point is to have unified defined rules for arena pointers, to allow
making safe assumptions everywhere when working with them. Both as a user
and in the kernel.

> 
>>   * arena pointers are converted to the kernel space for
>>     kfunc/struct_ops callback by the verifier
>>
>> With the documented and enforced semantics like this one way of
>> annotating and one annotation should be enough.
>>
>> What am I missing?
> 
> At the moment we have two consumers:
> - Planned sched_ext related kfuncs that need kernel space pointers.
> - Existing kfuncs with KF_ARENA_ARG:
>   - bpf_arena_alloc_pages
>   - bpf_arena_free_pages
>   - bpf_arena_reserve_pages
>   They, take a user space address. Looking at the code is appears that
>   all three can be changed to handle kernel space address.
>   On the other hand, neither of these *needs* the passed pointer to be
>   converted to a kernel side arena pointer. So that would be just some
>   useless work.
> 
> So there are two valid use cases.

I think having more than one way of how to pass an arena pointer to
the kernel will create more confusion than bring value.

It seems to me the existing bpf_arena_* kfuncs accept user space
address for historical reasons (we just tried something that worked),
not by design exactly.

btw, Eduard, I get very confused by how you say "user space".. you
mean the 32bit value representing the BPF arena pointer, right?

Anyways, I think we should converge on the approach to arena pointers
handling before landing anything.

Let's use __arena suffix as annotation mechanism, fine. But
I really wouldn't like to end up with N annotations for each
permutation of (non-)nullable and kern/user...

I'll submit the resolve_btfids patches asap to not block on that.


> 
> ...

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Eduard Zingerman]

On Tue, 2026-08-04 at 14:55 -0700, Ihor Solodrai wrote:
> On 8/4/26 2:34 PM, Eduard Zingerman wrote:
> > On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
> > > On 8/4/26 1:22 PM, Eduard Zingerman wrote:
> > > > On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
> > > > > On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
> > > > > > On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
> > > > > > > [...]
> > > > > 
> > > > > > 
> > > > > > So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
> > > > > > think we want to introduce and support yet another mechanism for arena
> > > > > > argument annotations. If we do, we'll be stuck with a mess of
> > > > > > supporting two/three ways of doing the same thing for the foreseeable future.
> > > > > 
> > > > > I think one major difference is that KF_ARENA_ARG* things were mostly for
> > > > > annotating the vmlinux.h with the right address space label before, but didn't
> > > > > carry any semantic meaning for the kfunc's type checks.
> > > > > 
> > > > > That changes with these suffixes though. The pointer will be translated when
> > > > > passed into the kfunc. IMO it would be odd to diverge for this particular case,
> > > > > since we use suffixes for every other case where we constrain the input type of
> > > > > the kfunc argument or give it special meaning.
> > > > > 
> > > > > We also want to have similar annotation on struct_ops callbacks, where we also
> > > > > use suffixes, so it seemed better to keep it consistent.
> > > > 
> > > > I agree that we should follow the principle of least surprise here and
> > > > use suffixes, as everything else uses suffixes as well.
> > > 
> > > Ok, I understand the motivation. Let's say we use the suffixes.
> > > 
> > > Should this enable getting rid of KF_ARENA* flags then? For the
> > > purposes of generating address_space(1), we can also just check the
> > > name suffix, no?
> > 
> > That would be ideal, yes.
> > 
> > > > 
> > > > And yes, the __arena and KF_ARENA_ARG* annotations have different
> > > > semantics:
> > > > - __arena means that user space arena address is passed as is
> > > > - KF_ARENA_ARG* means that a user space address is converted
> > > >   to a kernel space address before passing.
> > > 
> > > Also I am a little confused about whether we *need* to be able to
> > > express two distinct meanings of "arena pointer" or not?
> > > 
> > > My understanding is that "arena pointer" is a feature of an arg type
> > > that has a single meaning: the pointer has one base in BPF world, and
> > > a different base when executed in the kernel.
> > > 
> > > The things that are missing is auto-conversion (Tejun's RFC [1]) and more
> > > comprehensive support of PTR_TO_ARENA in the verifier.
> > > 
> > > This is still only one "arena" annotation per arg. Do we actually need
> > > the proliferation of __arena, __arena__nullable and/or __arena_kern,
> > > __arena_user? Can't we have a single defined semantics of how arena
> > > pointers are supposed to work?
> > > 
> > > I can imagine something like follows:
> > >   * arena pointers can not be null, check for nulls
> > >     before passing from BPF prog to the kernel
> > 
> > We are deliberately lax when handling arena and don't do any kind of
> > value tracking there. So e.g. the following won't work:
> > 
> >   if (foo->ptr) {
> >     ...
> >     kfunc(foo->ptr);
> >   }
> > 
> > Unless compiler decides to keep foo->ptr in a register. I'm not sure
> > whether enforcing non-null here from the verifier side is the right
> > call.
> 
> I don't argue for this particular semantics, it's just an example.
> 
> My point is to have unified defined rules for arena pointers, to allow
> making safe assumptions everywhere when working with them. Both as a user
> and in the kernel.
> 
> > 
> > >   * arena pointers are converted to the kernel space for
> > >     kfunc/struct_ops callback by the verifier
> > > 
> > > With the documented and enforced semantics like this one way of
> > > annotating and one annotation should be enough.
> > > 
> > > What am I missing?
> > 
> > At the moment we have two consumers:
> > - Planned sched_ext related kfuncs that need kernel space pointers.
> > - Existing kfuncs with KF_ARENA_ARG:
> >   - bpf_arena_alloc_pages
> >   - bpf_arena_free_pages
> >   - bpf_arena_reserve_pages
> >   They, take a user space address. Looking at the code is appears that
> >   all three can be changed to handle kernel space address.
> >   On the other hand, neither of these *needs* the passed pointer to be
> >   converted to a kernel side arena pointer. So that would be just some
> >   useless work.
> > 
> > So there are two valid use cases.
> 
> I think having more than one way of how to pass an arena pointer to
> the kernel will create more confusion than bring value.

That might be the case.

> It seems to me the existing bpf_arena_* kfuncs accept user space
> address for historical reasons (we just tried something that worked),
> not by design exactly.

What makes you think so?

> btw, Eduard, I get very confused by how you say "user space".. you
> mean the 32bit value representing the BPF arena pointer, right?

Nope:

  static long compute_pgoff(struct bpf_arena *arena, long uaddr)
  {
	return (u32)(uaddr - (u32)arena->user_vm_start) >> PAGE_SHIFT;
  }

  static int arena_reserve_pages(struct bpf_arena *arena, long uaddr, u32 page_cnt)
  {
	...
	if (uaddr & ~PAGE_MASK)
		return 0;

	pgoff = compute_pgoff(arena, uaddr);
	if (pgoff + page_cnt > page_cnt_max)
		return -EINVAL;
	...
   }

  __bpf_kfunc int bpf_arena_reserve_pages(void *p__map, void *ptr__ign, u32 page_cnt)
  {
	...
	return arena_reserve_pages(arena, (long)ptr__ign, page_cnt);
  }

ptr__ign/uaddr is a 64-bit user space address.

> 
> Anyways, I think we should converge on the approach to arena pointers
> handling before landing anything.
> 
> Let's use __arena suffix as annotation mechanism, fine. But
> I really wouldn't like to end up with N annotations for each
> permutation of (non-)nullable and kern/user...
> 
> I'll submit the resolve_btfids patches asap to not block on that.
> 
> 
> > 
> > ...

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Ihor Solodrai]

On 8/4/26 3:05 PM, Eduard Zingerman wrote:
> On Tue, 2026-08-04 at 14:55 -0700, Ihor Solodrai wrote:
>> On 8/4/26 2:34 PM, Eduard Zingerman wrote:
>>> On Tue, 2026-08-04 at 14:19 -0700, Ihor Solodrai wrote:
>>>> On 8/4/26 1:22 PM, Eduard Zingerman wrote:
>>>>> On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
>>>>>> On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
>>>>>>> On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
>>>>>>>> [...]
>>>>>>
>>>>
>>>> What am I missing?
>>>
>>> At the moment we have two consumers:
>>> - Planned sched_ext related kfuncs that need kernel space pointers.
>>> - Existing kfuncs with KF_ARENA_ARG:
>>>   - bpf_arena_alloc_pages
>>>   - bpf_arena_free_pages
>>>   - bpf_arena_reserve_pages
>>>   They, take a user space address. Looking at the code is appears that
>>>   all three can be changed to handle kernel space address.
>>>   On the other hand, neither of these *needs* the passed pointer to be
>>>   converted to a kernel side arena pointer. So that would be just some
>>>   useless work.
>>>
>>> So there are two valid use cases.
>>
>> I think having more than one way of how to pass an arena pointer to
>> the kernel will create more confusion than bring value.
> 
> That might be the case.
> 
>> It seems to me the existing bpf_arena_* kfuncs accept user space
>> address for historical reasons (we just tried something that worked),
>> not by design exactly.
> 
> What makes you think so?

The fact that sched_ext needs to use a different way, which is why
this thread exists.  But you may be right that these are just two
different use-cases, and each does what makes sense for it.

> 
>> btw, Eduard, I get very confused by how you say "user space".. you
>> mean the 32bit value representing the BPF arena pointer, right?
> 
> Nope:
> 
>   static long compute_pgoff(struct bpf_arena *arena, long uaddr)
>   {
> 	return (u32)(uaddr - (u32)arena->user_vm_start) >> PAGE_SHIFT;
>   }
> 
>   static int arena_reserve_pages(struct bpf_arena *arena, long uaddr, u32 page_cnt)
>   {
> 	...
> 	if (uaddr & ~PAGE_MASK)
> 		return 0;
> 
> 	pgoff = compute_pgoff(arena, uaddr);
> 	if (pgoff + page_cnt > page_cnt_max)
> 		return -EINVAL;
> 	...
>    }
> 
>   __bpf_kfunc int bpf_arena_reserve_pages(void *p__map, void *ptr__ign, u32 page_cnt)
>   {
> 	...
> 	return arena_reserve_pages(arena, (long)ptr__ign, page_cnt);
>   }
> 
> ptr__ign/uaddr is a 64-bit user space address.

I see, thanks for the explanation.

> 
>>
>> Anyways, I think we should converge on the approach to arena pointers
>> handling before landing anything.
>>
>> Let's use __arena suffix as annotation mechanism, fine. But
>> I really wouldn't like to end up with N annotations for each
>> permutation of (non-)nullable and kern/user...
>>
>> I'll submit the resolve_btfids patches asap to not block on that.
>>
>>
>>>
>>> ...

Re: [PATCH dwarves] btf_encoder: Infer arena kfunc arguments from suffixes

[Kumar Kartikeya Dwivedi]

On Tue Aug 4, 2026 at 11:19 PM CEST, Ihor Solodrai wrote:
> On 8/4/26 1:22 PM, Eduard Zingerman wrote:
>> On Tue, 2026-08-04 at 21:27 +0200, Kumar Kartikeya Dwivedi wrote:
>>> On Tue Aug 4, 2026 at 8:43 PM CEST, Ihor Solodrai wrote:
>>>> On 8/3/26 5:55 AM, Kumar Kartikeya Dwivedi wrote:
>>>>> [...]
>>>
>>>>
>>>> So while I understand the reluctance to add KF_ARENA_ARG3..N, I don't
>>>> think we want to introduce and support yet another mechanism for arena
>>>> argument annotations. If we do, we'll be stuck with a mess of
>>>> supporting two/three ways of doing the same thing for the foreseeable future.
>>>
>>> I think one major difference is that KF_ARENA_ARG* things were mostly for
>>> annotating the vmlinux.h with the right address space label before, but didn't
>>> carry any semantic meaning for the kfunc's type checks.
>>>
>>> That changes with these suffixes though. The pointer will be translated when
>>> passed into the kfunc. IMO it would be odd to diverge for this particular case,
>>> since we use suffixes for every other case where we constrain the input type of
>>> the kfunc argument or give it special meaning.
>>>
>>> We also want to have similar annotation on struct_ops callbacks, where we also
>>> use suffixes, so it seemed better to keep it consistent.
>>
>> I agree that we should follow the principle of least surprise here and
>> use suffixes, as everything else uses suffixes as well.
>
> Ok, I understand the motivation. Let's say we use the suffixes.
>
> Should this enable getting rid of KF_ARENA* flags then? For the
> purposes of generating address_space(1), we can also just check the
> name suffix, no?
>
>>
>> And yes, the __arena and KF_ARENA_ARG* annotations have different
>> semantics:
>> - __arena means that user space arena address is passed as is
>> - KF_ARENA_ARG* means that a user space address is converted
>>   to a kernel space address before passing.
>
> Also I am a little confused about whether we *need* to be able to
> express two distinct meanings of "arena pointer" or not?
>
> My understanding is that "arena pointer" is a feature of an arg type
> that has a single meaning: the pointer has one base in BPF world, and
> a different base when executed in the kernel.
>
> The things that are missing is auto-conversion (Tejun's RFC [1]) and more
> comprehensive support of PTR_TO_ARENA in the verifier.
>
> This is still only one "arena" annotation per arg. Do we actually need
> the proliferation of __arena, __arena__nullable and/or __arena_kern,
> __arena_user? Can't we have a single defined semantics of how arena
> pointers are supposed to work?
>

I agree that we should simply have one __arena tag. It has a well defined
meaning for the program already, so shouldn't be confusing when seen on input
argument in struct_ops callback, or when passed into a kfunc as an output.

From the kernel's PoV, as Ihor said, it will rebased to the kernel base.
I wouldn't unnecessarily burden the consumers of this stuff to worry about
which side it should be translated to, that can be unambiguously derived from
the context in which it is used.

Having the ability to specify __nullable also makes sense. If for nothing else,
we already do that for every other pointer argument in a kfunc, otherwise assume
the argument is non-NULL unless the kfunc definition specifically opts into a
non-NULL argument. As a side benefit, it leads to more optimized JIT sequence.

In Tejun's branch, this came up already: only one of the callback or kfunc
really needed the __nullable annotation, the other was supposed to accept a
proper argument without the need to represent optionality.

I think we should have had such behavior for global functions too, but when they
were first implemented we hardcoded OR_NULL into the received type for a memory
pointer, and thus live with explicit __nonnull annotation now, to avoid breaking
compat if we change default behavior.

> I can imagine something like follows:
>   * arena pointers can not be null, check for nulls
>     before passing from BPF prog to the kernel
>   * arena pointers are converted to the kernel space for
>     kfunc/struct_ops callback by the verifier
>
> With the documented and enforced semantics like this one way of
> annotating and one annotation should be enough.
>
> What am I missing?
>
> [1] https://lore.kernel.org/bpf/20260713024414.3759854-1-tj@kernel.org/
>
>>
>> It appears, though, that from the BPF program side having an address
>> space annotation on the kfunc parameter would be helpful, as it avoids
>> an additional cast.
>> > Tbh, it sounds like we want __arena_user and __arena_kern suffixes.
>>
>>> I agree that all of these should be using type tags, but we're not there yet.
>>
>> Let's put aside the type tags discussion for the time being.
>>
>> ...