Re: [PATCH] perf: avoid lockdep warning in self-monitoring perf_event_open

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hard deadlock and unsafe `this_cpu_ptr()` usage due to bypass of IPI context in `perf_install_in_context()`.
--

commit edfe32c20b9adaadf4bb22117c091b1b0e31a92d
Author: Haocheng Yu <l1za0.sec@gmail.com>

perf: avoid lockdep warning in self-monitoring perf_event_open

This commit attempts to fix a lockdep warning by adding a fast path for
self-monitoring in perf_install_in_context(). It directly calls
__perf_install_in_context() instead of using task_function_call() when the
target task is current.

> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 7935d5663944e..6e689f2dafbd9 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
[ ... ]
> @@ -3199,6 +3199,10 @@ perf_install_in_context(struct perf_event_context *ctx,
>  	 */
>  	smp_mb();
>  again:
> +	if (task == current) {
> +		__perf_install_in_context(event);
> +		return;
> +	}

[Severity: High]
Does this direct call to __perf_install_in_context() introduce a regression
by running with preemption and interrupts enabled?

Since perf_install_in_context() only holds ctx->mutex here, preemption and
interrupts are still active. When __perf_install_in_context() is called
directly instead of via IPI, it executes:

kernel/events/core.c:__perf_install_in_context() {
    ...
	struct perf_cpu_context *cpuctx = this_cpu_ptr(&perf_cpu_context);
    ...
}

Will this trigger a warning for using this_cpu_ptr() in preemptible context,
and potentially allow the task to migrate and corrupt per-CPU data?

Additionally, __perf_install_in_context() acquires locks without disabling
interrupts:

kernel/events/core.c:__perf_install_in_context() {
    ...
	raw_spin_lock(&cpuctx->ctx.lock);
	if (ctx->task) {
		raw_spin_lock(&ctx->lock);
    ...
}

If a hardware PMU interrupt or a timer tick (like perf_event_task_tick())
fires on the same CPU while these locks are held, could this regression
result in a hard deadlock when the interrupt handler attempts to acquire
them again?

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