From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1162157AbbKERwm (ORCPT ); Thu, 5 Nov 2015 12:52:42 -0500 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:52137 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932525AbbKERwl convert rfc822-to-8bit (ORCPT ); Thu, 5 Nov 2015 12:52:41 -0500 Subject: Re: [PATCHv2 3/4] arm-cci: Add routines to enable/disable all counters To: Mark Rutland References: <1445346326-30820-1-git-send-email-suzuki.poulose@arm.com> <1445346326-30820-4-git-send-email-suzuki.poulose@arm.com> <20151104182854.GH23860@leverpostej> <563B2C01.80701@arm.com> <20151105172756.GH32247@leverpostej> Cc: linux-arm-kernel@lists.infradead.org, punit.agrawal@arm.com, arm@kernel.org, linux-kernel@vger.kernel.org From: "Suzuki K. Poulose" Message-ID: <563B9765.9070708@arm.com> Date: Thu, 5 Nov 2015 17:52:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20151105172756.GH32247@leverpostej> X-OriginalArrivalTime: 05 Nov 2015 17:52:37.0278 (UTC) FILETIME=[C1E1CBE0:01D117F2] X-MC-Unique: c1W2zEKcSOq5dmxwttJRjw-1 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/11/15 17:27, Mark Rutland wrote: >>> Can we not get rid of the mask entirely? The combination of used_mask >>> and each event's hwc->state tells us which counters are actually in use. >> >> The problem is that neither hwc->state nor the cci_pmu->hw_events->events is >> protected by pmu_lock, while enable/disable counter is. So we cannot really >> rely on ((struct perf_event *)(cci_pmu->hw_events->events[counter]))->hw->state. > > They must be protected somehow, or we'd have races against cross-calls > and/or the interrupt handler. > > Are we protected due to being cpu-affine with interrupts disabled when > modifying these, is there some other mechanism that protects us, or do > we have additional problems here? > Each perf_event is allocated a counter id atomically using the bit mask. So, once the id is allocated nobody messes with that id from the PMU side. And, the hw->state may have its own protection within the generic perf layer(which I haven't checked). Thanks Suzuki