linux-kernel - Re: [PATCH v9] perf: add qcom 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:   Mon, 6 Feb 2017 14:11:36 -0500
From:   "Leeder, Neil" <nleeder@...eaurora.org>
To:     Mark Rutland <mark.rutland@....com>
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,
        nleeder@...eaurora.org
Subject: Re: [PATCH v9] perf: add qcom l2 cache perf events driver

Hi Mark,
Thanks for those comments - I'll add the fixes.

On 2/6/2017 10:48 AM, Mark Rutland wrote:
> I'm still concerned by this use of the filter_match callback, because it
> depends on the set of other active events, and can change as other
> events are scheduled in and out.
>
> When we schedule in two conflicting events A and B in order, B will fail
> its filter match. When we scheduled out A and B in order, B will succeed
> its filter match.
>
> The perf core does not expect this inconsistency, and this appears to
> break the timing update logic in event_sched_out(), when unconditionally
> called from ctx_sched_out() as part of perf_rotate_context().
>
> I would feel much happier if we dropped l2_cache_filter_match(), at
> least for the timebeing, and handled this as we do for other cases of
> intra-pmu resource contention.
>
> We can then consider the filter_match addition on its own at a later
> point.

So could this be detected in get_event_idx, the same way we handle 
counter resource contention? That would eliminate filter_match, and it's 
the same way its done in armv7 
(arch/arm/kernel/perf_event_v7.c:krait_pmu_get_event_idx()).

It's less obvious to the user, but seeing 2 events being rotated so they 
each have ~50% coverage should provide a hint that the user did 
something wrong, so I think that would work.

Thanks,

Neil
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.