Re: [PATCHv8 bpf-next 04/29] bpf: Use mutex lock pool for bpf trampolines

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Spurious `-EAGAIN` failures in unrelated ftrace, kprobe, and livepatch registrations due to hash collisions in the shared trampoline lock pool.
--

commit 618668a1ad7a4e1838f3d78fb1f6af04ade24704
Author: Jiri Olsa <jolsa@kernel.org>

bpf: Use mutex lock pool for bpf trampolines

This commit replaces the per-trampoline mutex with a 32-bucket mutex lock pool
to avoid lockdep warnings when locking all trampolines simultaneously during
tracing_multi link attachments.

> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> index a4298a25d4bae..c0b4732627bef 100644
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c

[ ... ]

> @@ -99,12 +128,12 @@ static int bpf_tramp_ftrace_ops_func(struct ftrace_ops *ops, unsigned long ip,
>  	 *   cleanup_direct_functions_after_ipmodify
>  	 *
>  	 * In both cases, direct_mutex is already locked. Use
> -	 * mutex_trylock(&tr->mutex) to avoid deadlock in race condition
> -	 * (something else is making changes to this same trampoline).
> +	 * mutex_trylock(select_trampoline_lock(tr)) to avoid deadlock in race condition
> +	 * (something else holds the same pool lock).
>  	 */
> -	if (!mutex_trylock(&tr->mutex)) {
> -		/* sleep 1 ms to make sure whatever holding tr->mutex makes
> -		 * some progress.
> +	if (!mutex_trylock(select_trampoline_lock(tr))) {

[Severity: High]
Does this change introduce spurious -EAGAIN failures for unrelated tracing
registrations due to hash collisions?

With the move to a 32-bucket lock pool, if one thread holds a pool lock during
a BPF update, and another thread concurrently registers an ftrace op (like
attaching a kprobe or livepatch) on an unrelated function whose trampoline
hashes to the same bucket, the mutex_trylock() will fail and return -EAGAIN.

Since callers like register_kprobe() do not loop on -EAGAIN, could this cause
unrelated observability tools to fail their attachments unexpectedly?

> +		/* sleep 1 ms to make sure whatever holding select_trampoline_lock(tr)
> +		 * makes some progress.
>  		 */
>  		msleep(1);
>  		return -EAGAIN;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260606123955.345967-5-jolsa@kernel.org?part=1