From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753619AbbLKPsf (ORCPT ); Fri, 11 Dec 2015 10:48:35 -0500 Received: from mga03.intel.com ([134.134.136.65]:41321 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751938AbbLKPse (ORCPT ); Fri, 11 Dec 2015 10:48:34 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,414,1444719600"; d="scan'208";a="858873567" From: Alexander Shishkin To: Peter Zijlstra Cc: Ingo Molnar , linux-kernel@vger.kernel.org, vince@deater.net, eranian@google.com, Arnaldo Carvalho de Melo , Mathieu Poirier Subject: Re: [PATCH v0 3/5] perf: Introduce instruction trace filtering In-Reply-To: <20151211153354.GY6356@twins.programming.kicks-ass.net> References: <1449840998-29902-1-git-send-email-alexander.shishkin@linux.intel.com> <1449840998-29902-4-git-send-email-alexander.shishkin@linux.intel.com> <20151211150236.GU6356@twins.programming.kicks-ass.net> <87wpslatut.fsf@ashishki-desk.ger.corp.intel.com> <20151211153354.GY6356@twins.programming.kicks-ass.net> User-Agent: Notmuch/0.21 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Fri, 11 Dec 2015 17:48:03 +0200 Message-ID: <87si39aswc.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > On Fri, Dec 11, 2015 at 05:27:22PM +0200, Alexander Shishkin wrote: >> Peter Zijlstra writes: >> >> > On Fri, Dec 11, 2015 at 03:36:36PM +0200, Alexander Shishkin wrote: >> >> +static int perf_event_itrace_filters_setup(struct perf_event *event) >> >> +{ >> >> + int ret; >> >> + >> >> + /* >> >> + * We can't use event_function_call() here, because that would >> >> + * require ctx::mutex, but one of our callers is called with >> >> + * mm::mmap_sem down, which would cause an inversion, see bullet >> >> + * (2) in put_event(). >> >> + */ >> >> + do { >> >> + if (READ_ONCE(event->state) != PERF_EVENT_STATE_ACTIVE) { >> >> + ret = event->pmu->itrace_filter_setup(event); >> >> + break; >> > >> > So this is tricky, if its not active it can be any moment, there is >> > nothing serializing against that. >> >> Indeed. But we should be able to call pmu::itrace_filter_setup() >> multiple times, so if after this we re-check that the event is still >> inactive, we can return, otherwise proceed with the cross-call. Does >> this make sense? > > Dunno, I worry :-) > > What if: > > if (READ_ONCE(event->state) != PERF_EVENT_STATE_ACTIVE) { > // we were INACTIVE, but now the event gets scheduled in > // on _another_ CPU > event->pmu->itrace_filter_setup() := { > if (event->state == PERF_EVENT_STATE_ACTIVE) { > /* muck with hardware */ > } > } > } > > Here too I feel a strict validation vs programming split would make sense. > > We can always call the validation thing, we must not call the program > thing !ACTIVE is a clear and simple rule. Ah, but pmu::itrace_filter_setup() does not touch the hardware, pmu::start() does. The former keeps an array of, say, MSR values ready for programming in event::hw and the latter actually writes the MSRs. So the above example should not be a problem. So in a way validation and programming are split already. And PT, for example, won't have it any other way, you can only program stuff into the registers while tracing is disabled. Regards, -- Alex