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

["Emil Tsalapatis" <emil@etsalapatis.com>]

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;