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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d084e81c-19eb-4424-9fa9-868b75786527@linux.intel.com>
Date: Mon, 24 Mar 2025 13:26:23 -0400
From: "Liang, Kan" <kan.liang@...ux.intel.com>
To: peterz@...radead.org, mingo@...hat.com, acme@...nel.org,
 namhyung@...nel.org, irogers@...gle.com, adrian.hunter@...el.com,
 linux-kernel@...r.kernel.org
Cc: ak@...ux.intel.com, eranian@...gle.com, dapeng1.mi@...ux.intel.com
Subject: Re: [PATCH] perf/x86/intel/ds: Fix counter backwards of non-precise
 events counters-snapshotting

Hi Peter,

The patch is to fix a counters-snapshotting backwards issue with
non-precise events in freq mode. Could you please pick it up as well?

Thanks,
Kan

On 2025-02-04 4:05 p.m., kan.liang@...ux.intel.com wrote:
> From: Kan Liang <kan.liang@...ux.intel.com>
> 
> The counter backwards may be observed in the PMI handler when
> counters-snapshotting some non-precise events in the freq mode.
> 
> For the non-precise events, it's possible the counters-snapshotting
> records a positive value for an overflowed PEBS event. Then the HW
> auto-reload mechanism reset the counter to 0 immediately. Because the
> pebs_event_reset is cleared in the freq mode, which doesn't set the
> PERF_X86_EVENT_AUTO_RELOAD.
> In the PMI handler, 0 will be read rather than the positive value
> recorded in the counters-snapshotting record.
> 
> The counters-snapshotting case has to be specially handled. Since the
> event value has been updated when processing the counters-snapshotting
> record, only needs to set the new period for the counter via
> x86_pmu_set_period().
> 
> Signed-off-by: Kan Liang <kan.liang@...ux.intel.com>
> ---
>  arch/x86/events/intel/ds.c | 21 +++++++++++++++++++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c
> index 46aaaeae0c8d..e8f808905871 100644
> --- a/arch/x86/events/intel/ds.c
> +++ b/arch/x86/events/intel/ds.c
> @@ -2377,8 +2377,25 @@ __intel_pmu_pebs_last_event(struct perf_event *event,
>  			 */
>  			intel_pmu_save_and_restart_reload(event, count);
>  		}
> -	} else
> -		intel_pmu_save_and_restart(event);
> +	} else {
> +		/*
> +		 * For a non-precise event, it's possible the
> +		 * counters-snapshotting records a positive value for the
> +		 * overflowed event. Then the HW auto-reload mechanism
> +		 * reset the counter to 0 immediately, because the
> +		 * pebs_event_reset is cleared if the PERF_X86_EVENT_AUTO_RELOAD
> +		 * is not set. The counter backwards may be observed in a
> +		 * PMI handler.
> +		 *
> +		 * Since the event value has been updated when processing the
> +		 * counters-snapshotting record, only needs to set the new
> +		 * period for the counter.
> +		 */
> +		if (is_pebs_counter_event_group(event))
> +			static_call(x86_pmu_set_period)(event);
> +		else
> +			intel_pmu_save_and_restart(event);
> +	}
>  }
>  
>  static __always_inline void


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ