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: <20201218110114.GD5258@gaia>
Date:   Fri, 18 Dec 2020 11:01:15 +0000
From:   Catalin Marinas <catalin.marinas@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
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 Fri, Dec 18, 2020 at 09:56:02AM +0530, Viresh Kumar wrote:
> 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.

Normally we freeze the arm64 tree around the -rc6 prior to the merging
window to give the patches a bit of time in linux-next. This time
around, given the holidays, Linus even stated that if not already in
-next at 5.10, it won't be pulled: https://lkml.org/lkml/2020/12/13/290.

So please re-post at -rc1 with the acks in place.

-- 
Catalin

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ