linux-kernel - Re: [PATCH v2 3/4] perf/x86/intel: implement LBR callstacks context synchronization

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: <c39bc36c-b1eb-f9b4-edbb-47de3b1f32ca@linux.intel.com>
Date:   Wed, 16 Oct 2019 17:07:05 +0300
From:   Alexey Budankov <alexey.budankov@...ux.intel.com>
To:     "Liang, Kan" <kan.liang@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Stephane Eranian <eranian@...gle.com>,
        Ian Rogers <irogers@...gle.com>,
        Song Liu <songliubraving@...com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/4] perf/x86/intel: implement LBR callstacks context
 synchronization


On 16.10.2019 16:39, Alexey Budankov wrote:
> On 16.10.2019 15:20, Liang, Kan wrote:
>>
>>
>> On 10/16/2019 5:50 AM, Alexey Budankov wrote:
>>>
>>> Implement intel_pmu_lbr_sync_task_ctx() method that updates counter
>>> of the events that requested LBR callstack data on a sample.
>>>
>>> The counter can be zero for the case when task context belongs to
>>> a thread that has just come from a block on a futex and the context
>>> contains saved (lbr_stack_state == LBR_VALID) LBR register values.
>>>
>>> For the values to be restored at LBR registers on the next thread's
>>> switch-in event it copies the counter value that is expected to be
>>> non zero from the previous equivalent task perf event context.
>>>
>>> Signed-off-by: Alexey Budankov <alexey.budankov@...ux.intel.com>
>>> ---
>>>   arch/x86/events/intel/lbr.c  | 9 +++++++++
>>>   arch/x86/events/perf_event.h | 3 +++
>>>   2 files changed, 12 insertions(+)
>>>
>>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>>> index ea54634eabf3..152a3f8b516a 100644
>>> --- a/arch/x86/events/intel/lbr.c
>>> +++ b/arch/x86/events/intel/lbr.c
>>> @@ -417,6 +417,15 @@ static void __intel_pmu_lbr_save(struct x86_perf_task_context *task_ctx)
>>>       cpuc->last_log_id = ++task_ctx->log_id;
>>>   }
>>>   +void intel_pmu_lbr_sync_task_ctx(struct x86_perf_task_context *one,
>>> +                 struct x86_perf_task_context *another)
>>> +{
>>> +    if (!one || !another)
>>> +        return;
>>> +
>>> +    one->lbr_callstack_users = another->lbr_callstack_users;
>>
>> We may want to swap here?
> 
> Well, in this particular case lbr_callstack_users has to stay consistent 
> with the amount of events in task perf event context that requested 
> LBR callstack.

Tested swap version and it also fixes the initial issue.
After more code revising swap looks like the correct operation here.
Nice catch. Thanks!

~Alexey

> 
> ~Alexey
> 
>>
>> Thanks,
>> Kan
>>
>>> +}
>>> +
>>>   void intel_pmu_lbr_sched_task(struct perf_event_context *ctx, bool sched_in)
>>>   {
>>>       struct cpu_hw_events *cpuc = this_cpu_ptr(&cpu_hw_events);
>>> diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
>>> index a25e6d7eb87b..3e0087c06fc9 100644
>>> --- a/arch/x86/events/perf_event.h
>>> +++ b/arch/x86/events/perf_event.h
>>> @@ -1024,6 +1024,9 @@ void intel_pmu_store_pebs_lbrs(struct pebs_lbr *lbr);
>>>     void intel_ds_init(void);
>>>   +void intel_pmu_lbr_sync_task_ctx(struct x86_perf_task_context *one,
>>> +                 struct x86_perf_task_context *another);
>>> +
>>>   void intel_pmu_lbr_sched_task(struct perf_event_context *ctx, bool sched_in);
>>>     u64 lbr_from_signext_quirk_wr(u64 val);
>>>
>>
>