linux-kernel - Re: [PATCH 1/3] x86/resctrl: Get max rmid and occupancy scale directly from CPUID instead of cpuinfo

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, 17 Jun 2019 10:30:48 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Fenghua Yu <fenghua.yu@...el.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, H Peter Anvin <hpa@...or.com>,
        Christopherson Sean J <sean.j.christopherson@...el.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Radim Krcmar <rkrcmar@...hat.com>,
        Ravi V Shankar <ravi.v.shankar@...el.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        x86 <x86@...nel.org>, Jacob Pan <jacob.jun.pan@...ux.intel.com>,
        Len Brown <lenb@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH 1/3] x86/resctrl: Get max rmid and occupancy scale
 directly from CPUID instead of cpuinfo_x86

On Mon, Jun 17, 2019 at 01:09:09AM -0700, Fenghua Yu wrote:
> I just keep the code a bit uniform around the calling area where
> a few functions are called. So get_cqm_info() makes the code a bit more
> readable.
> 
>         init_scattered_cpuid_features(c);
>         init_speculation_control(c);
> +       get_cqm_info(c);
> 
>         /*
>          * Clear/Set all flags overridden by options, after probe.
>          * This needs to happen each time we re-probe, which may happen
>          * several times during CPU initialization.
>          */
>         apply_forced_caps(c);
> }
> 
> Maybe not? If the function is not good, I can directly put the code here?

If you want to have it cleaner, make that a separate patch and say so in
the commit message. Patches should do one logical thing and not mix up
different changes which makes review harder.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.