linux-kernel - Re: [PATCH v2 01/15] perf/x86/lbr: Simplify the exposure check for the LBR

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]

Message-ID: <f5196090-ce8b-43a7-bfb6-e060881b2ea2@gmail.com>
Date:   Fri, 23 Dec 2022 10:12:52 +0800
From:   Like Xu <like.xu.linux@...il.com>
To:     Peter Zijlstra <peterz@...radead.org>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     kan.liang@...ux.intel.com, wei.w.wang@...el.com,
        Andi Kleen <ak@...ux.intel.com>,
        "Paolo Bonzini - Distinguished Engineer (kernel-recipes.org) (KVM HoF)" 
        <pbonzini@...hat.com>, Jim Mattson <jmattson@...gle.com>,
        kvm list <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Yang Weijiang <weijiang.yang@...el.com>
Subject: Re: [PATCH v2 01/15] perf/x86/lbr: Simplify the exposure check for
 the LBR_INFO registers

On 23/12/2022 1:41 am, Sean Christopherson wrote:
> On Thu, Dec 22, 2022, Like Xu wrote:
>> Hi Peter, would you help apply this one in your tip/perf tree,
>> as it doesn't seem to be closely tied to the KVM changes. Thanks.
>>
>> On 25/11/2022 12:05 pm, Yang Weijiang wrote:
>>> From: Like Xu <like.xu@...ux.intel.com>
>>>
>>> The x86_pmu.lbr_info is 0 unless explicitly initialized, so there's
>>> no point checking x86_pmu.intel_cap.lbr_format.
>>>
>>> Cc: Peter Zijlstra <peterz@...radead.org>
>>> Reviewed-by: Kan Liang <kan.liang@...ux.intel.com>
>>> Reviewed-by: Andi Kleen <ak@...ux.intel.com>
>>> Signed-off-by: Like Xu <like.xu@...ux.intel.com>
>>> Signed-off-by: Yang Weijiang <weijiang.yang@...el.com>
>>> ---
>>>    arch/x86/events/intel/lbr.c | 4 +---
>>>    1 file changed, 1 insertion(+), 3 deletions(-)
>>>
>>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>>> index 4dbde69c423b..e7caabfa1377 100644
>>> --- a/arch/x86/events/intel/lbr.c
>>> +++ b/arch/x86/events/intel/lbr.c
>>> @@ -1606,12 +1606,10 @@ void __init intel_pmu_arch_lbr_init(void)
>>>     */
>>>    void x86_perf_get_lbr(struct x86_pmu_lbr *lbr)
>>>    {
>>> -	int lbr_fmt = x86_pmu.intel_cap.lbr_format;
>>> -
>>>    	lbr->nr = x86_pmu.lbr_nr;
>>>    	lbr->from = x86_pmu.lbr_from;
>>>    	lbr->to = x86_pmu.lbr_to;
>>> -	lbr->info = (lbr_fmt == LBR_FORMAT_INFO) ? x86_pmu.lbr_info : 0;
>>> +	lbr->info = x86_pmu.lbr_info;
> 
> This stable-worthy a bug fix, no?  E.g. won't the existing code misreport lbr->info
> if the format is LBR_FORMAT_INFO2?

Sure, we need "Cc: stable@...r.kernel.org" in order not to lose misprediction 
and cycles
information on the LBR_FORMAT_INFO2 platforms like Goldmont plus.

> 
>>>    }
>>>    EXPORT_SYMBOL_GPL(x86_perf_get_lbr);