linux-kernel - Re: [PATCH 2/2] perf/x86/intel: Fix PMI handling for Intel PT

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]

Date:	Thu, 11 Jun 2015 16:00:20 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Cc:	Ingo Molnar <mingo@...hat.com>, linux-kernel@...r.kernel.org,
	adrian.hunter@...el.com, x86@...nel.org, hpa@...or.com,
	acme@...radead.org
Subject: Re: [PATCH 2/2] perf/x86/intel: Fix PMI handling for Intel PT

On Thu, Jun 11, 2015 at 03:13:57PM +0300, Alexander Shishkin wrote:
> @@ -1426,7 +1426,23 @@ perf_event_nmi_handler(unsigned int cmd, struct pt_regs *regs)
>  	u64 finish_clock;
>  	int ret;
>  
> -	if (!atomic_read(&active_events))
> +	/*
> +	 * Intel PT is a separate PMUs, it doesn't increment active_events
> +	 * nor does it use resources associated with it, such as DS area.
> +	 * However, it still uses the same PMI handler, so here we need
> +	 * to make sure to call it *also* if any PT events are present.
> +	 *
> +	 * BTS events currently increment active_events implicitly through
> +	 * x86_reserve_hardware(), where it acts as DS area reference
> +	 * counter, so no need to check x86_lbr_exclusive_bts counter here;
> +	 * otherwise we'd have to do the same for BTS.
> +	 *
> +	 * Theoretically, they could be made into separate PMI handlers, but
> +	 * that can create additional challenges as PT uses the same PMI status
> +	 * register as x86_pmu.
> +	 */
> +	if (!atomic_read(&active_events) &&
> +	    !atomic_read(&x86_pmu.lbr_exclusive[x86_lbr_exclusive_pt]))
>  		return NMI_DONE;
>  

Urgh, sad. That's two cache misses instead of one. Cant we somehow keep
that a single value to read?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/