Re: [PATCH bpf-next v2 2/7] bpf: Drop redundant hash_buf from map_get_hash operation

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] Computing the SHA-256 hash of a large frozen array map without scheduling points can cause a prolonged CPU stall (soft lockup).
--

commit 5b323404e84282b52180b843142a5d52b5becb22
Author: Daniel Borkmann <daniel@iogearbox.net>

bpf: Drop redundant hash_buf from map_get_hash operation

This commit simplifies the map_get_hash operation by dropping the unused
hash_buf_size argument and removing a redundant self-copy in
array_map_get_hash. The bpf_map_get_info_by_fd function is updated to invoke
it without passing the buffer.

> diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
> --- a/kernel/bpf/arraymap.c
> +++ b/kernel/bpf/arraymap.c

[ ... ]

> -static int array_map_get_hash(struct bpf_map *map, u32 hash_buf_size,
> -			       void *hash_buf)
> +static int array_map_get_hash(struct bpf_map *map)
>  {
>  	struct bpf_array *array = container_of(map, struct bpf_array, map);
>  
>  	sha256(array->value, (u64)array->elem_size * array->map.max_entries,
> -	       hash_buf);
> -	memcpy(array->map.sha, hash_buf, sizeof(array->map.sha));
> +	       array->map.sha);

[Severity: High]
This isn't a bug introduced by this patch, but could this sha256 call cause
a soft lockup for very large array maps?

BPF array maps can be allocated with very large sizes. Since sha256 processes
the data sequentially without yielding, computing it over a gigabyte-sized
array might take seconds of uninterrupted CPU time.

Because bpf_map_get_info_by_fd unconditionally triggers this computation when
a user requests the map hash, is there a risk that this could be used to
repeatedly stall the CPU, leading to RCU stalls or soft lockup warnings?

>  	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260601150248.394863-1-daniel@iogearbox.net?part=2