lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250424163221.GD18306@noisy.programming.kicks-ass.net>
Date: Thu, 24 Apr 2025 18:32:21 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Ingo Molnar <mingo@...hat.com>, LKML <linux-kernel@...r.kernel.org>,
	"Liang, Kan" <kan.liang@...ux.intel.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
	Arnaldo Carvalho de Melo <acme@...nel.org>,
	Ian Rogers <irogers@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Namhyung Kim <namhyung@...nel.org>,
	Ravi Bangoria <ravi.bangoria@....com>,
	linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 3/4] perf: Remove too early and redundant CPU hotplug
 handling

On Thu, Apr 24, 2025 at 06:11:27PM +0200, Frederic Weisbecker wrote:
> The CPU hotplug handlers are called twice: at prepare and online stage.
> 
> Their role is to:
> 
> 1) Enable/disable a CPU context. This is irrelevant and even buggy at
>    the prepare stage because the CPU is still offline. On early
>    secondary CPU up, creating an event attached to that CPU might
>    silently fail because the CPU context is observed as online but the
>    context installation's IPI failure is ignored.
> 
> 2) Update the scope cpumasks and re-migrate the events accordingly in
>    the CPU down case. This is irrelevant at the prepare stage.
> 
> 3) Remove the events attached to the context of the offlining CPU. It
>    even uses an (unnecessary) IPI for it. This is also irrelevant at the
>    prepare stage.
> 
> Also none of the *_PREPARE and *_STARTING architecture perf related CPU
> hotplug callbacks rely on CPUHP_PERF_PREPARE.
> 
> CPUHP_AP_PERF_ONLINE is enough and the right place to perform the work.

Oh hey, that's curious indeed.

> Signed-off-by: Frederic Weisbecker <frederic@...nel.org>
> ---
>  include/linux/cpuhotplug.h | 1 -
>  kernel/cpu.c               | 5 -----
>  2 files changed, 6 deletions(-)
> 
> diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
> index 1987400000b4..df366ee15456 100644
> --- a/include/linux/cpuhotplug.h
> +++ b/include/linux/cpuhotplug.h
> @@ -60,7 +60,6 @@ enum cpuhp_state {
>  	/* PREPARE section invoked on a control CPU */
>  	CPUHP_OFFLINE = 0,
>  	CPUHP_CREATE_THREADS,
> -	CPUHP_PERF_PREPARE,
>  	CPUHP_PERF_X86_PREPARE,
>  	CPUHP_PERF_X86_AMD_UNCORE_PREP,
>  	CPUHP_PERF_POWER,
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index b08bb34b1718..a59e009e0be4 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -2069,11 +2069,6 @@ static struct cpuhp_step cpuhp_hp_states[] = {
>  		.teardown.single	= NULL,
>  		.cant_stop		= true,
>  	},
> -	[CPUHP_PERF_PREPARE] = {
> -		.name			= "perf:prepare",
> -		.startup.single		= perf_event_init_cpu,
> -		.teardown.single	= perf_event_exit_cpu,
> -	},
>  	[CPUHP_RANDOM_PREPARE] = {
>  		.name			= "random:prepare",
>  		.startup.single		= random_prepare_cpu,
> -- 
> 2.48.1
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ