[PATCH bpf-next v1 0/2] Open up res_spin_lock() in all contexts

[PATCH bpf-next v1 0/2] Open up res_spin_lock() in all contexts

[Kumar Kartikeya Dwivedi]

Spin off first patch with added tests from [0]. See commits for details.

  [0]: https://lore.kernel.org/bpf/20260719113551.1294284-1-memxor@gmail.com

Kumar Kartikeya Dwivedi (2):
  bpf: Allow bpf_res_spin_lock() in all contexts
  selftests/bpf: Test res spin locks in tracing programs

 kernel/bpf/verifier.c                         |  2 +
 .../bpf/progs/verifier_helper_restricted.c    | 66 +++++++++++++++++++
 2 files changed, 68 insertions(+)


base-commit: 87267b89459813cb50ab5377e076b639c07b4491
-- 
2.53.0

[PATCH bpf-next v1 1/2] bpf: Allow bpf_res_spin_lock() in all contexts

[Kumar Kartikeya Dwivedi]

There is no particular reason to keep bpf_res_spin_lock() disabled in
tracing programs, since it is safe against reentrancy and deadlocks.
Remove the restriction for tracing programs covered by the predicate
is_tracing_prog_type().

This is a prerequisite before the definition of is_tracing_prog_type()
is updated to include raw_tp, fentry, fexit, and fmod_ret. Existing
tracing programs will be updated to use bpf_res_spin_lock() instead when
it is available.

Acked-by: Eduard Zingerman <eddyz87@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
 kernel/bpf/verifier.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 52be0a118cce..57a76c21d624 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -17815,7 +17815,9 @@ static int check_map_prog_compatibility(struct bpf_verifier_env *env,
 			verbose(env, "socket filter progs cannot use bpf_spin_lock yet\n");
 			return -EINVAL;
 		}
+	}
 
+	if (btf_record_has_field(map->record, BPF_SPIN_LOCK)) {
 		if (is_tracing_prog_type(prog_type)) {
 			verbose(env, "tracing progs cannot use bpf_spin_lock yet\n");
 			return -EINVAL;
-- 
2.53.0

[PATCH bpf-next v1 2/2] selftests/bpf: Test res spin locks in tracing programs

[Kumar Kartikeya Dwivedi]

Exercise bpf_res_spin_lock() from kprobe, tracepoint, perf event, and raw
tracepoint programs. Keep the existing bpf_spin_lock() rejection checks so
the tests cover the split verifier policy for the two lock types.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
 .../bpf/progs/verifier_helper_restricted.c    | 66 +++++++++++++++++++
 1 file changed, 66 insertions(+)

diff --git a/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c b/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c
index 889c9b78b912..b3beb8f6dd19 100644
--- a/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c
+++ b/tools/testing/selftests/bpf/progs/verifier_helper_restricted.c
@@ -10,6 +10,18 @@ struct val {
 	struct bpf_spin_lock l;
 };
 
+struct bpf_res_spin_lock {
+	__u32 val;
+};
+
+struct res_val {
+	int cnt;
+	struct bpf_res_spin_lock l;
+};
+
+extern int bpf_res_spin_lock(struct bpf_res_spin_lock *lock) __ksym;
+extern void bpf_res_spin_unlock(struct bpf_res_spin_lock *lock) __ksym;
+
 struct {
 	__uint(type, BPF_MAP_TYPE_ARRAY);
 	__uint(max_entries, 1);
@@ -17,6 +29,28 @@ struct {
 	__type(value, struct val);
 } map_spin_lock SEC(".maps");
 
+struct {
+	__uint(type, BPF_MAP_TYPE_ARRAY);
+	__uint(max_entries, 1);
+	__type(key, int);
+	__type(value, struct res_val);
+} map_res_spin_lock SEC(".maps");
+
+static __always_inline int use_res_spin_lock(void)
+{
+	struct res_val *val;
+	int key = 0;
+
+	val = bpf_map_lookup_elem(&map_res_spin_lock, &key);
+	if (!val)
+		return 0;
+	if (bpf_res_spin_lock(&val->l))
+		return 0;
+	val->cnt++;
+	bpf_res_spin_unlock(&val->l);
+	return 0;
+}
+
 SEC("kprobe")
 __description("bpf_ktime_get_coarse_ns is forbidden in BPF_PROG_TYPE_KPROBE")
 __failure __msg("program of this type cannot use helper bpf_ktime_get_coarse_ns")
@@ -165,4 +199,36 @@ l0_%=:	exit;						\
 	: __clobber_all);
 }
 
+SEC("kprobe")
+__description("bpf_res_spin_lock is allowed in BPF_PROG_TYPE_KPROBE")
+__success
+int res_spin_lock_bpf_prog_type_kprobe(void *ctx)
+{
+	return use_res_spin_lock();
+}
+
+SEC("tracepoint")
+__description("bpf_res_spin_lock is allowed in BPF_PROG_TYPE_TRACEPOINT")
+__success
+int res_spin_lock_bpf_prog_type_tracepoint(void *ctx)
+{
+	return use_res_spin_lock();
+}
+
+SEC("perf_event")
+__description("bpf_res_spin_lock is allowed in BPF_PROG_TYPE_PERF_EVENT")
+__success
+int res_spin_lock_bpf_prog_type_perf_event(void *ctx)
+{
+	return use_res_spin_lock();
+}
+
+SEC("raw_tracepoint")
+__description("bpf_res_spin_lock is allowed in BPF_PROG_TYPE_RAW_TRACEPOINT")
+__success
+int res_spin_lock_bpf_prog_type_raw_tracepoint(void *ctx)
+{
+	return use_res_spin_lock();
+}
+
 char _license[] SEC("license") = "GPL";
-- 
2.53.0

[PATCH bpf-next v1 0/2] Open up res_spin_lock for tracing programs, fix is_tracing_prog_type()

[Kumar Kartikeya Dwivedi]

Patches in the set first open up res_spin_lock in all program types. The
second patch goes back to addressing the technical debt highlighted in [0].
While for programs affected by the second patch don't need res_spin_lock
to be opened up (since it was already allowed in those program types due
to the oversight in is_tracing_prog_type()), it is timely to do so now.

  [0]: https://lore.kernel.org/bpf/DJ3W8IZ08WBT.VTRTP72FSWVO@gmail.com

See commits for details.

Kumar Kartikeya Dwivedi (2):
  bpf: Allow bpf_res_spin_lock() in all contexts
  bpf: Fix is_tracing_prog_type() to cover fentry/fexit/fmod_ret

 kernel/bpf/verifier.c                         | 48 +++++++++++--------
 .../selftests/bpf/prog_tests/linked_list.c    |  6 +--
 .../selftests/bpf/prog_tests/map_btf.c        | 19 ++++----
 .../selftests/bpf/progs/map_in_map_btf.c      |  2 +-
 .../selftests/bpf/progs/normal_map_btf.c      |  2 +-
 .../selftests/bpf/progs/refcounted_kptr.c     | 10 ++--
 .../bpf/progs/refcounted_kptr_fail.c          |  5 +-
 .../bpf/progs/verifier_helper_restricted.c    |  4 ++
 8 files changed, 51 insertions(+), 45 deletions(-)


base-commit: ecf11bc5f56abb3a2219a8c75e8a5b54467d1781
-- 
2.53.0

[PATCH bpf-next v1 1/2] bpf: Allow bpf_res_spin_lock() in all contexts

[Kumar Kartikeya Dwivedi]

There is no particular reason to keep bpf_res_spin_lock() disabled in
tracing programs, since it is safe against reentrancy and deadlocks.
Remove the restriction for tracing programs covered by the predicate
is_tracing_prog_type().

This is a prerequisite before the definition of is_tracing_prog_type()
is updated to include raw_tp, fentry, fexit, and fmod_ret. Existing
tracing programs will be updated to use bpf_res_spin_lock() instead when
it is available.

Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
---
 kernel/bpf/verifier.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 4446f0bde88b..bb6e16668d0d 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -17815,7 +17815,9 @@ static int check_map_prog_compatibility(struct bpf_verifier_env *env,
 			verbose(env, "socket filter progs cannot use bpf_spin_lock yet\n");
 			return -EINVAL;
 		}
+	}
 
+	if (btf_record_has_field(map->record, BPF_SPIN_LOCK)) {
 		if (is_tracing_prog_type(prog_type)) {
 			verbose(env, "tracing progs cannot use bpf_spin_lock yet\n");
 			return -EINVAL;
-- 
2.53.0

Re: [PATCH bpf-next v1 1/2] bpf: Allow bpf_res_spin_lock() in all contexts

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] bpf_res_spin_lock() remains disabled for socket filter programs, contradicting the commit title 'Allow bpf_res_spin_lock() in all contexts'.

Pre-existing issues:
- [High] When parsing BTF fields, the check for a valid `bpf_res_spin_lock` offset incorrectly checks `rec->spin_lock_off` instead of `rec->res_spin_lock_off`.
--

--- Patch [1]: [PATCH bpf-next v1 1/2] bpf: Allow bpf_res_spin_lock() in all contexts ---
commit 88a844e18ff8ff22c90389d929ce1c63353b73fe
Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>

bpf: Allow bpf_res_spin_lock() in all contexts

This commit removes the restriction that prevents tracing programs from
using bpf_res_spin_lock(). The stated goal is to allow its use in all
contexts.

> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 4446f0bde88b5..bb6e16668d0d1 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -17815,7 +17815,9 @@ static int check_map_prog_compatibility(struct bpf_verifier_env *env,
>  			verbose(env, "socket filter progs cannot use bpf_spin_lock yet\n");
>  			return -EINVAL;
>  		}
> +	}

[Severity: Medium]
The commit message states the goal is to allow bpf_res_spin_lock() in all
contexts. However, just above this block in check_map_prog_compatibility(),
there is a check that still blocks it:

	if (btf_record_has_field(map->record, BPF_SPIN_LOCK | BPF_RES_SPIN_LOCK)) {
		if (prog_type == BPF_PROG_TYPE_SOCKET_FILTER) {

Does this contradict the commit title by leaving it disabled for socket
filter programs?

>  
> +	if (btf_record_has_field(map->record, BPF_SPIN_LOCK)) {
>  		if (is_tracing_prog_type(prog_type)) {
>  			verbose(env, "tracing progs cannot use bpf_spin_lock yet\n");
>  			return -EINVAL;


While reviewing this area, I also noticed a potential issue in another file.

kernel/bpf/btf.c:btf_parse_fields() {
	...
		case BPF_RES_SPIN_LOCK:
			WARN_ON_ONCE(rec->spin_lock_off >= 0);
			/* Cache offset for faster lookup at runtime */
			rec->res_spin_lock_off = rec->fields[i].offset;
			break;
	...
}

[Severity: High]
This is a pre-existing issue, but does this WARN_ON_ONCE() incorrectly check 
rec->spin_lock_off instead of rec->res_spin_lock_off?

If a user creates a BPF map value containing both a bpf_spin_lock and a
bpf_res_spin_lock, and BPF_SPIN_LOCK is parsed first, rec->spin_lock_off will
be non-negative. When BPF_RES_SPIN_LOCK is then processed, it appears this
would trivially trigger the warning, which could cause a kernel panic if
panic_on_warn is enabled.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719113551.1294284-1-memxor@gmail.com?part=1

Re: [PATCH bpf-next v1 1/2] bpf: Allow bpf_res_spin_lock() in all contexts

[Kumar Kartikeya Dwivedi]

On Sun Jul 19, 2026 at 1:56 PM CEST, sashiko-bot wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
>
> New issues:
> - [Medium] bpf_res_spin_lock() remains disabled for socket filter programs, contradicting the commit title 'Allow bpf_res_spin_lock() in all contexts'.
>
> Pre-existing issues:
> - [High] When parsing BTF fields, the check for a valid `bpf_res_spin_lock` offset incorrectly checks `rec->spin_lock_off` instead of `rec->res_spin_lock_off`.
> --
>
> --- Patch [1]: [PATCH bpf-next v1 1/2] bpf: Allow bpf_res_spin_lock() in all contexts ---
> commit 88a844e18ff8ff22c90389d929ce1c63353b73fe
> Author: Kumar Kartikeya Dwivedi <memxor@gmail.com>
>
> bpf: Allow bpf_res_spin_lock() in all contexts
>
> This commit removes the restriction that prevents tracing programs from
> using bpf_res_spin_lock(). The stated goal is to allow its use in all
> contexts.
>
>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>> index 4446f0bde88b5..bb6e16668d0d1 100644
>> --- a/kernel/bpf/verifier.c
>> +++ b/kernel/bpf/verifier.c
>> @@ -17815,7 +17815,9 @@ static int check_map_prog_compatibility(struct bpf_verifier_env *env,
>>  			verbose(env, "socket filter progs cannot use bpf_spin_lock yet\n");
>>  			return -EINVAL;
>>  		}
>> +	}
>
> [Severity: Medium]
> The commit message states the goal is to allow bpf_res_spin_lock() in all
> contexts. However, just above this block in check_map_prog_compatibility(),
> there is a check that still blocks it:
>
> 	if (btf_record_has_field(map->record, BPF_SPIN_LOCK | BPF_RES_SPIN_LOCK)) {
> 		if (prog_type == BPF_PROG_TYPE_SOCKET_FILTER) {
>
> Does this contradict the commit title by leaving it disabled for socket
> filter programs?
>

We don't want to enable it for socket filter.

>>
>> +	if (btf_record_has_field(map->record, BPF_SPIN_LOCK)) {
>>  		if (is_tracing_prog_type(prog_type)) {
>>  			verbose(env, "tracing progs cannot use bpf_spin_lock yet\n");
>>  			return -EINVAL;
>
>
> While reviewing this area, I also noticed a potential issue in another file.
>
> kernel/bpf/btf.c:btf_parse_fields() {
> 	...
> 		case BPF_RES_SPIN_LOCK:
> 			WARN_ON_ONCE(rec->spin_lock_off >= 0);
> 			/* Cache offset for faster lookup at runtime */
> 			rec->res_spin_lock_off = rec->fields[i].offset;
> 			break;
> 	...
> }
>
> [Severity: High]
> This is a pre-existing issue, but does this WARN_ON_ONCE() incorrectly check
> rec->spin_lock_off instead of rec->res_spin_lock_off?
>
> If a user creates a BPF map value containing both a bpf_spin_lock and a
> bpf_res_spin_lock, and BPF_SPIN_LOCK is parsed first, rec->spin_lock_off will
> be non-negative. When BPF_RES_SPIN_LOCK is then processed, it appears this
> would trivially trigger the warning, which could cause a kernel panic if
> panic_on_warn is enabled.

Yeah, it's not that serious, but will fix when I respin (or follow up separately).
That said, for now, I will wait for more reviews.

Re: [PATCH bpf-next v1 1/2] bpf: Allow bpf_res_spin_lock() in all contexts

[Emil Tsalapatis]

On Sun Jul 19, 2026 at 7:35 AM EDT, Kumar Kartikeya Dwivedi wrote:
> There is no particular reason to keep bpf_res_spin_lock() disabled in
> tracing programs, since it is safe against reentrancy and deadlocks.
> Remove the restriction for tracing programs covered by the predicate
> is_tracing_prog_type().
>
> This is a prerequisite before the definition of is_tracing_prog_type()
> is updated to include raw_tp, fentry, fexit, and fmod_ret. Existing
> tracing programs will be updated to use bpf_res_spin_lock() instead when
> it is available.
>
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>

Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>

I assume we do not want to enable this for socket filter to avoid
additional testing, since there is currently no clear use case for
it?

> ---
>  kernel/bpf/verifier.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 4446f0bde88b..bb6e16668d0d 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -17815,7 +17815,9 @@ static int check_map_prog_compatibility(struct bpf_verifier_env *env,
>  			verbose(env, "socket filter progs cannot use bpf_spin_lock yet\n");
>  			return -EINVAL;
>  		}
> +	}
>  
> +	if (btf_record_has_field(map->record, BPF_SPIN_LOCK)) {
>  		if (is_tracing_prog_type(prog_type)) {
>  			verbose(env, "tracing progs cannot use bpf_spin_lock yet\n");
>  			return -EINVAL;

Re: [PATCH bpf-next v1 1/2] bpf: Allow bpf_res_spin_lock() in all contexts

[Eduard Zingerman]

On Sun, 2026-07-19 at 13:35 +0200, Kumar Kartikeya Dwivedi wrote:
> There is no particular reason to keep bpf_res_spin_lock() disabled in
> tracing programs, since it is safe against reentrancy and deadlocks.
> Remove the restriction for tracing programs covered by the predicate
> is_tracing_prog_type().
> 
> This is a prerequisite before the definition of is_tracing_prog_type()
> is updated to include raw_tp, fentry, fexit, and fmod_ret. Existing
> tracing programs will be updated to use bpf_res_spin_lock() instead when
> it is available.
> 
> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
> ---

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

Talking to Kumar, tracing bpf_res_spin_lock() with a program that uses
bpf_res_spin_lock shouldn't be an issue.

...