linux-kernel - Re: [PATCH V3 1/3] arm64: topology: Avoid the have

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, 18 Dec 2020 09:56:02 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     Ionela Voinescu <ionela.voinescu@....com>,
        Will Deacon <will@...nel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3 1/3] arm64: topology: Avoid the have_policy check

On 17-12-20, 10:55, Catalin Marinas wrote:
> Hi Viresh,
> 
> On Thu, Dec 17, 2020 at 01:27:32PM +0530, Viresh Kumar wrote:
> > On 15-12-20, 11:04, Viresh Kumar wrote:
> > > Every time I have stumbled upon this routine, I get confused with the
> > > way 'have_policy' is used and I have to dig in to understand why is it
> > > so. Here is an attempt to make it easier to understand, and hopefully it
> > > is an improvement.
> > > 
> > > The 'have_policy' check was just an optimization to avoid writing
> > > to amu_fie_cpus in case we don't have to, but that optimization itself
> > > is creating more confusion than the real work. Lets just do that if all
> > > the CPUs support AMUs. It is much cleaner that way.
> > > 
> > > Reviewed-by: Ionela Voinescu <ionela.voinescu@....com>
> > > Signed-off-by: Viresh Kumar <viresh.kumar@...aro.org>
> > > ---
> > > V3:
> > > - Added Reviewed by tag.
> > 
> > Catalin, please pick the first two patches for 5.11. I will send the
> > last one separately later on.
> 
> I haven't figured out whether these are fixes (a cover letter would
> help ;)). They look like generic improvements to me

Right they are and since the merge window just opened I thought these
don't really need to wait for another full cycle to get in.

> and given that we
> are already in the 5.11 merging window, they would probably need to wait
> until 5.12.

Whatever you decide :)

-- 
viresh