linux-kernel - Re: [PATCH 2/3] RISC-V: Move cpuid to hartid mapping to SMP.

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:   Sat, 5 Jan 2019 18:13:31 -0800
From:   Atish Patra <atish.patra@....com>
To:     Anup Patel <anup@...infault.org>
Cc:     "linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
        Albert Ou <aou@...s.berkeley.edu>,
        Daniel Lezcano <daniel.lezcano@...aro.org>,
        Dmitriy Cherkasov <dmitriy@...-tech.org>,
        Jason Cooper <jason@...edaemon.net>,
        "linux-kernel@...r.kernel.org List" <linux-kernel@...r.kernel.org>,
        Marc Zyngier <marc.zyngier@....com>,
        Michael Clark <michaeljclark@....com>,
        Palmer Dabbelt <palmer@...ive.com>,
        Patrick Stählin <me@...ki.ch>,
        Rob Herring <robh@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Damien Le Moal <Damien.LeMoal@....com>
Subject: Re: [PATCH 2/3] RISC-V: Move cpuid to hartid mapping to SMP.

On 12/26/18 7:38 PM, Anup Patel wrote:
> On Thu, Dec 27, 2018 at 4:39 AM Atish Patra <atish.patra@....com> wrote:
>>
>> Currently, logical CPU id to physical hartid mapping is
>> defined for both smp and non-smp configurations. This
>> is not required as we need this only for smp configuration.
>> The mapping function can define directly boot_cpu_hartid
>> for non-smp usecase.
>>
>> The reverse mapping function i.e. hartid to cpuid can be called
>> for any valid but not booted harts. So it should return default
>> cpu 0 only if it is a boot hartid
>>
>> Signed-off-by: Atish Patra <atish.patra@....com>
>> ---
>>   arch/riscv/include/asm/smp.h | 13 +++++++++++--
>>   arch/riscv/kernel/setup.c    |  2 ++
>>   2 files changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
>> index 41aa73b4..8f30300f 100644
>> --- a/arch/riscv/include/asm/smp.h
>> +++ b/arch/riscv/include/asm/smp.h
>> @@ -22,12 +22,13 @@
>>   /*
>>    * Mapping between linux logical cpu index and hartid.
>>    */
>> -extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
>> -#define cpuid_to_hartid_map(cpu)    __cpuid_to_hartid_map[cpu]
>>
>> +extern unsigned long boot_cpu_hartid;
>>   struct seq_file;
>>
>>   #ifdef CONFIG_SMP
>> +extern unsigned long __cpuid_to_hartid_map[NR_CPUS];
>> +#define cpuid_to_hartid_map(cpu)    __cpuid_to_hartid_map[cpu]
>>
>>   /* print IPI stats */
>>   void show_ipi_stats(struct seq_file *p, int prec);
>> @@ -58,7 +59,15 @@ static inline void show_ipi_stats(struct seq_file *p, int prec)
>>
>>   static inline int riscv_hartid_to_cpuid(int hartid)
>>   {
>> +       if (hartid == boot_cpu_hartid)
>>                  return 0;
>> +       else
>> +               return -1;
>> +}
>> +static inline unsigned long cpuid_to_hartid_map(int cpu)
>> +{
>> +
>> +       return boot_cpu_hartid;
>>   }
>>
>>   static inline void riscv_cpuid_to_hartid_mask(const struct cpumask *in,
>> diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
>> index 2c290e6a..bd4d7b85 100644
>> --- a/arch/riscv/kernel/setup.c
>> +++ b/arch/riscv/kernel/setup.c
>> @@ -83,6 +83,7 @@ EXPORT_SYMBOL(empty_zero_page);
>>   atomic_t hart_lottery;
>>   unsigned long boot_cpu_hartid;
>>
>> +#ifdef CONFIG_SMP
>>   unsigned long __cpuid_to_hartid_map[NR_CPUS] = {
>>          [0 ... NR_CPUS-1] = INVALID_HARTID
>>   };
>> @@ -91,6 +92,7 @@ void __init smp_setup_processor_id(void)
>>   {
>>          cpuid_to_hartid_map(0) = boot_cpu_hartid;
>>   }
>> +#endif
> 
> Please move __cpuid_to_hartid_map[] and smp_setup_processor_id()
> to arch/riscv/kernel/smp.c
> 

Will do. Thanks for the review.

> Otherwise, looks good to me.
> 
> Reviewed-by: Anup Patel <anup@...infault.org>
> 

Regards,
Atish