Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Wed, 21 Sep 2022 09:53:04 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     Duoming Zhou <duoming@zju.edu.cn>
Cc:     peterz@infradead.org, linux-perf-users@vger.kernel.org,
        linux-kernel@vger.kernel.org, mingo@redhat.com, acme@kernel.org,
        mark.rutland@arm.com, alexander.shishkin@linux.intel.com,
        jolsa@kernel.org, namhyung@kernel.org, tglx@linutronix.de,
        bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
        hpa@zytor.com
Subject: Re: [PATCH V2] perf/x86/rapl: fix deadlock in rapl_pmu_event_stop
Message-ID: <YyrC4OyP2BtY8tNl@gmail.com>
References: <20220920014447.71946-1-duoming@zju.edu.cn>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220920014447.71946-1-duoming@zju.edu.cn>
Precedence: bulk


* Duoming Zhou <duoming@zju.edu.cn> wrote:

> There is a deadlock in rapl_pmu_event_stop(), the process is
> shown below:
> 
>     (thread 1)                 |        (thread 2)
> rapl_pmu_event_stop()          | rapl_hrtimer_handle()
>  ...                           |  if (!pmu->n_active)
>  raw_spin_lock_irqsave() //(1) |  ...
>   ...                          |
>   hrtimer_cancel()             |  raw_spin_lock_irqsave() //(2)
>   (block forever)
> 
> We hold pmu->lock in position (1) and use hrtimer_cancel() to wait
> rapl_hrtimer_handle() to stop, but rapl_hrtimer_handle() also need
> pmu->lock in position (2). As a result, the rapl_pmu_event_stop()
> will be blocked forever.
> 
> This patch extracts hrtimer_cancel() from the protection of
> raw_spin_lock_irqsave(). As a result, the rapl_hrtimer_handle()
> could obtain the pmu->lock.
> 
> Fixes: 65661f96d3b3 ("perf/x86: Add RAPL hrtimer support")
> Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
> ---
> Changes in v2:
>   - Move hrtimer_cancel() to the end of rapl_pmu_event_stop() function.
> 
>  arch/x86/events/rapl.c | 7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/events/rapl.c b/arch/x86/events/rapl.c
> index 77e3a47af5a..7c110092c83 100644
> --- a/arch/x86/events/rapl.c
> +++ b/arch/x86/events/rapl.c
> @@ -281,8 +281,6 @@ static void rapl_pmu_event_stop(struct perf_event *event, int mode)
>  	if (!(hwc->state & PERF_HES_STOPPED)) {
>  		WARN_ON_ONCE(pmu->n_active <= 0);
>  		pmu->n_active--;
> -		if (pmu->n_active == 0)
> -			hrtimer_cancel(&pmu->hrtimer);
>  
>  		list_del(&event->active_entry);
>  
> @@ -300,6 +298,11 @@ static void rapl_pmu_event_stop(struct perf_event *event, int mode)
>  		hwc->state |= PERF_HES_UPTODATE;
>  	}
>  
> +	if (!pmu->n_active) {
> +		raw_spin_unlock_irqrestore(&pmu->lock, flags);
> +		hrtimer_cancel(&pmu->hrtimer);
> +		return;
> +	}

Looks racy now: AFAICS now it's possible for rapl_hrtimer_handle() to 
execute at an arbitrary moment after pmu->lock is dropped - which could be 
use-after-free after cleanup_rapl_pmus() executes and the PMU is freed, 
right?

There's also the quality-of-implementation issue of the hrtimer executing 
in a delayed fashion for the *next* event that may have been added, leading 
to possibly unexpected results.

Thanks,

	Ingo