linux-kernel - Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver

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:   Fri, 16 Sep 2016 17:40:11 +0100
From:   Mark Rutland <mark.rutland@....com>
To:     Neil Leeder <nleeder@...eaurora.org>
Cc:     Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will.deacon@....com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org,
        Mark Langsdorf <mlangsdo@...hat.com>,
        Mark Salter <msalter@...hat.com>, Jon Masters <jcm@...hat.com>,
        Timur Tabi <timur@...eaurora.org>, cov@...eaurora.org
Subject: Re: [PATCH v4 2/2] soc: qcom: add l2 cache perf events driver

On Fri, Sep 16, 2016 at 11:33:39AM -0400, Neil Leeder wrote:
> Hi Mark,
> Thank you for the thorough review. I will post an updated patchset
> which addresses all of your comments. There is just one outstanding
> comment which I have a question about:

[...]

> On 9/1/2016 12:30 PM, Mark Rutland wrote:
> > On Tue, Aug 30, 2016 at 01:01:33PM -0400, Neil Leeder wrote:
> >> +	/* Don't allow groups with mixed PMUs, except for s/w events */
> >> +	if (event->group_leader->pmu != event->pmu &&
> >> +	    !is_software_event(event->group_leader)) {
> >> +		dev_warn(&l2cache_pmu->pdev->dev,
> >> +			 "Can't create mixed PMU group\n");
> >> +		return -EINVAL;
> >> +	}
> >> +
> >> +	list_for_each_entry(sibling, &event->group_leader->sibling_list,
> >> +			    group_entry)
> >> +		if (sibling->pmu != event->pmu &&
> >> +		    !is_software_event(sibling)) {
> >> +			dev_warn(&l2cache_pmu->pdev->dev,
> >> +				 "Can't create mixed PMU group\n");
> >> +			return -EINVAL;
> >> +		}
> >> +
> >> +	hwc->idx = -1;
> >> +	hwc->config_base = event->attr.config;
> >> +
> >> +	/*
> >> +	 * Ensure all events are on the same cpu so all events are in the
> >> +	 * same cpu context, to avoid races on pmu_enable etc.
> >> +	 */
> >> +	slice = get_hml2_pmu(event->cpu);
> >> +	event->cpu = slice->on_cpu;
> > 
> > This could put an event on a different CPU to its group siblings, which
> > is broken.
> 
> This is the same logic as in arm-ccn.c:arm_ccn_pmu_event_init(), where there
> is a single CPU designated as the CPU to be used for all events.
>
> All events for this slice are forced to slice->on_cpu which is the CPU
> set in the cpumask for this slice.

The CCN is a little different. For the CCN, a single CPU is designated
to handle *all* events.

For this driver, a CPU is designated per-slice, judging by the existence
of hml2_pmu::on_cpu (unless that's superfluous). We've only verified
that the events are all for this PMU, not the same slice, and thus each
event->cpu may differ.

> I'm not sure how this can put an event on a different CPU to its group
> siblings?

In practice today, we'll try to schedule the event on it's group
leader's CPU, but accounting and subsequent manipulation could go wrong.

Thanks,
Mark.