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] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190325145019.GC6231@kernel.org>
Date:   Mon, 25 Mar 2019 11:50:19 -0300
From:   Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH] perf intel-pt: Fix TSC slip

Em Mon, Mar 25, 2019 at 03:51:35PM +0200, Adrian Hunter escreveu:
> A TSC packet can slip past MTC packets so that the timestamp appears to go
> backwards. One estimate is that can be up to about 40 CPU cycles, which is
> certainly less than 0x1000 TSC ticks, but accept slippage an order of
> magnitude more to be on the safe side.

thanks, applied to perf/urgent.

- Arnaldo
 
> Signed-off-by: Adrian Hunter <adrian.hunter@...el.com>
> Fixes: 79b58424b821c ("perf tools: Add Intel PT support for decoding MTC packets")
> Cc: stable@...r.kernel.org
> ---
>  .../util/intel-pt-decoder/intel-pt-decoder.c  | 20 ++++++++-----------
>  1 file changed, 8 insertions(+), 12 deletions(-)
> 
> diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
> index 6e03db142091..872fab163585 100644
> --- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
> +++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
> @@ -251,19 +251,15 @@ struct intel_pt_decoder *intel_pt_decoder_new(struct intel_pt_params *params)
>  		if (!(decoder->tsc_ctc_ratio_n % decoder->tsc_ctc_ratio_d))
>  			decoder->tsc_ctc_mult = decoder->tsc_ctc_ratio_n /
>  						decoder->tsc_ctc_ratio_d;
> -
> -		/*
> -		 * Allow for timestamps appearing to backwards because a TSC
> -		 * packet has slipped past a MTC packet, so allow 2 MTC ticks
> -		 * or ...
> -		 */
> -		decoder->tsc_slip = multdiv(2 << decoder->mtc_shift,
> -					decoder->tsc_ctc_ratio_n,
> -					decoder->tsc_ctc_ratio_d);
>  	}
> -	/* ... or 0x100 paranoia */
> -	if (decoder->tsc_slip < 0x100)
> -		decoder->tsc_slip = 0x100;
> +
> +	/*
> +	 * A TSC packet can slip past MTC packets so that the timestamp appears
> +	 * to go backwards. One estimate is that can be up to about 40 CPU
> +	 * cycles, which is certainly less than 0x1000 TSC ticks, but accept
> +	 * slippage an order of magnitude more to be on the safe side.
> +	 */
> +	decoder->tsc_slip = 0x10000;
>  
>  	intel_pt_log("timestamp: mtc_shift %u\n", decoder->mtc_shift);
>  	intel_pt_log("timestamp: tsc_ctc_ratio_n %u\n", decoder->tsc_ctc_ratio_n);
> -- 
> 2.17.1

-- 

- Arnaldo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ