linux-kernel - Re: [RFC 2/4] arch-topology: add a default implementation of store_cpu

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: <20220708094710.rxk6flrueegdsggr@bogus>
Date:   Fri, 8 Jul 2022 10:47:10 +0100
From:   Sudeep Holla <sudeep.holla@....com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Conor Dooley <Conor.Dooley@...rochip.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Sudeep Holla <sudeep.holla@....com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Palmer Dabbelt <palmer@...osinc.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Daire.McNamara@...rochip.com,
        Niklas Cassel <niklas.cassel@....com>,
        Damien Le Moal <damien.lemoal@...nsource.wdc.com>,
        Zong Li <zong.li@...ive.com>,
        Emil Renner Berthing <kernel@...il.dk>, hahnjo@...njo.de,
        Guo Ren <guoren@...nel.org>, Anup Patel <anup@...infault.org>,
        Atish Patra <atishp@...shpatra.org>, changbin.du@...el.com,
        Heiko Stuebner <heiko@...ech.de>, philipp.tomsich@...ll.eu,
        Rob Herring <robh@...nel.org>, Marc Zyngier <maz@...nel.org>,
        Viresh Kumar <viresh.kumar@...aro.org>,
        linux-riscv <linux-riscv@...ts.infradead.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        Brice.Goglin@...ia.fr
Subject: Re: [RFC 2/4] arch-topology: add a default implementation of
 store_cpu_topology()

On Fri, Jul 08, 2022 at 11:28:19AM +0200, Geert Uytterhoeven wrote:
> Hi Sudeep,
> 
> On Fri, Jul 8, 2022 at 11:22 AM Sudeep Holla <sudeep.holla@....com> wrote:
> > On Fri, Jul 08, 2022 at 08:35:57AM +0000, Conor.Dooley@...rochip.com wrote:
> > > On 08/07/2022 09:24, Sudeep Holla wrote:
> > > > On Thu, Jul 07, 2022 at 11:04:35PM +0100, Conor Dooley wrote:
> > > >> From: Conor Dooley <conor.dooley@...rochip.com>
> > > >>
> > > >> RISC-V & arm64 both use an almost identical method of filling in
> > > >> default vales for arch topology. Create a weakly defined default
> > > >> implementation with the intent of migrating both archs to use it.
> > > >>
> > > >> Signed-off-by: Conor Dooley <conor.dooley@...rochip.com>
> > > >> ---
> > > >>   drivers/base/arch_topology.c  | 19 +++++++++++++++++++
> > > >>   include/linux/arch_topology.h |  1 +
> > > >>   2 files changed, 20 insertions(+)
> > > >>
> > > >> diff --git a/drivers/base/arch_topology.c b/drivers/base/arch_topology.c
> > > >> index 441e14ac33a4..07e84c6ac5c2 100644
> > > >> --- a/drivers/base/arch_topology.c
> > > >> +++ b/drivers/base/arch_topology.c
> > > >> @@ -765,6 +765,25 @@ void update_siblings_masks(unsigned int cpuid)
> > > >>    }
> > > >>   }
> > > >>
> > > >> +void __weak store_cpu_topology(unsigned int cpuid)
> > >
> > > Does using __weak here make sense to you?
> > >
> >
> > I don't want any weak definition and arch to override as we know only
> > arm64 and RISC-V are the only users and they are aligned to have same
> > implementation. So weak definition doesn't make sense to me.
> >
> > > >
> > > > I prefer to have this as default implementation. So just get the risc-v
> > > > one pushed to upstream first(for v5.20) and get all the backports if required.
> > > > Next cycle(i.e. v5.21), you can move both RISC-V and arm64.
> > > >
> > >
> > > Yeah, that was my intention. I meant to label patch 1/4 as "PATCH"
> > > and (2,3,4)/4 as RFC but forgot. I talked with Palmer about doing
> > > the risc-v impl. and then migrate both on IRC & he seemed happy with
> > > it.
> > >
> >
> > Ah OK, good.
> >
> > > If you're okay with patch 1/4, I'll resubmit it as a standalone v2.
> > >
> >
> > That would be great, thanks. You can most the code to move to generic from
> > both arm64 and risc-v once we have this in v5.20-rc1
> 
> Why not ignore risc-v for now, and move the arm64 implementation to
> the generic code for v5.20, so every arch will have it at once?
>

We could but,
1. This arch_topology is new and has been going through lot of changes
   recently and having code there might make it difficult to backport
   changes that are required for RISC-V(my guess)

2. May be too late for v5.20, I would like to see if we can even drop tiny
   arm64 bit in the code. It may be risky to try that this late and also
   with other topology changes we already have queued.

Let me know if that makes sense.

-- 
Regards,
Sudeep