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]

Date:   Fri, 8 Jul 2022 10:02:10 +0000
From:   <Conor.Dooley@...rochip.com>
To:     <sudeep.holla@....com>
CC:     <paul.walmsley@...ive.com>, <palmer@...belt.com>,
        <palmer@...osinc.com>, <aou@...s.berkeley.edu>,
        <catalin.marinas@....com>, <will@...nel.org>,
        <gregkh@...uxfoundation.org>, <rafael@...nel.org>,
        <Daire.McNamara@...rochip.com>, <niklas.cassel@....com>,
        <damien.lemoal@...nsource.wdc.com>, <geert@...ux-m68k.org>,
        <zong.li@...ive.com>, <kernel@...il.dk>, <hahnjo@...njo.de>,
        <guoren@...nel.org>, <anup@...infault.org>,
        <atishp@...shpatra.org>, <changbin.du@...el.com>,
        <heiko@...ech.de>, <philipp.tomsich@...ll.eu>, <robh@...nel.org>,
        <maz@...nel.org>, <viresh.kumar@...aro.org>,
        <linux-riscv@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
        <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 08/07/2022 10:21, Sudeep Holla wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
> 
> 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.

Right. I had used __weak b/c I didn't know how to split the migration
into smaller patches per arch without breaking the build due to
multiple definitions of store_cpu_topology().

> 
>>>
>>> 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

Right, that sounds like a plan (well, pending geert's concerns).
Could I have your R-b on patch 1? The comments you made about
removing the duplicate function should be resolved.

Thanks,
Conor.