linux-kernel - Re: [PATCHv2 3/4] arm-cci: Add routines to enable/disable all counters

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] [day] [month] [year] [list]

Message-ID: <563B9765.9070708@arm.com>
Date:	Thu, 5 Nov 2015 17:52:37 +0000
From:	"Suzuki K. Poulose" <Suzuki.Poulose@....com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	linux-arm-kernel@...ts.infradead.org, punit.agrawal@....com,
	arm@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2 3/4] arm-cci: Add routines to enable/disable all
 counters

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

--
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/