linux-kernel - Re: [PATCH] LoongArch: Correct the calculation logic of thread

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: <358F43AAEDB45D43+d28a0011-5b9a-4e3e-a517-0c6d8933adae@uniontech.com>
Date: Wed, 26 Nov 2025 18:14:31 +0800
From: Qiang Ma <maqianga@...ontech.com>
To: Hengqi Chen <hengqi.chen@...il.com>
Cc: loongarch@...ts.linux.dev, linux-kernel@...r.kernel.org,
 Huacai Chen <chenhuacai@...nel.org>, kernel@...0n.name
Subject: Re: [PATCH] LoongArch: Correct the calculation logic of thread_count


在 2025/11/26 18:06, Hengqi Chen 写道:
> On Wed, Nov 26, 2025 at 5:47 PM Qiang Ma <maqianga@...ontech.com> wrote:
>>
>> On Wed, Nov 26, 2025 at 10:37 AM Qiang Ma<maqianga@...ontech.com> wrote:
>>
>>>    For thread_count, the current calculation method has a maximum of 255,
>>>    which may not be sufficient in the future. Therefore, we are correcting
>>>    it now.
>>>
>>>    Reference: SMBIOS Specification, 7.5 Processor Information (Type 4)[1]
>>>
>>>    [1]:https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.9.0.pdf
>>>
>>>    Signed-off-by: Qiang Ma<maqianga@...ontech.com>
>>>    ---
>>>     arch/loongarch/kernel/setup.c | 9 ++++++++-
>>>     1 file changed, 8 insertions(+), 1 deletion(-)
>>>
>>>    diff --git a/arch/loongarch/kernel/setup.c b/arch/loongarch/kernel/setup.c
>>>    index 25a87378e48e..760f5ce44384 100644
>>>    --- a/arch/loongarch/kernel/setup.c
>>>    +++ b/arch/loongarch/kernel/setup.c
>>>    @@ -56,6 +56,7 @@
>>>     #define SMBIOS_FREQLOW_MASK            0xFF
>>>     #define SMBIOS_CORE_PACKAGE_OFFSET     0x23
>>>     #define SMBIOS_THREAD_PACKAGE_OFFSET   0x25
>>>    +#define SMBIOS_THREAD_PACKAGE_2_OFFSET 0x2E
>>>     #define LOONGSON_EFI_ENABLE            (1 << 3)
>>>
>>>     unsigned long fw_arg0, fw_arg1, fw_arg2;
>>>    @@ -120,13 +121,19 @@ static void __init parse_cpu_table(const struct dmi_header *dm)
>>>     {
>>>            long freq_temp = 0;
>>>            char *dmi_data = (char *)dm;
>>>    +       u8 thread_count;
>>>    +       u16 thread_count2;
>>>
>>>            freq_temp = ((*(dmi_data + SMBIOS_FREQHIGH_OFFSET) << 8) +
>>>                            ((*(dmi_data + SMBIOS_FREQLOW_OFFSET)) & SMBIOS_FREQLOW_MASK));
>>>            cpu_clock_freq = freq_temp * 1000000;
>>>
>>>            loongson_sysconf.cpuname = (void *)dmi_string_parse(dm, dmi_data[16]);
>>>    -       loongson_sysconf.cores_per_package = *(dmi_data + SMBIOS_THREAD_PACKAGE_OFFSET);
>>>    +       thread_count = *(dmi_data + SMBIOS_THREAD_PACKAGE_OFFSET);
>>>    +       thread_count2 = *(u16 *)(dmi_data + SMBIOS_THREAD_PACKAGE_2_OFFSET);
>>>
>>> You have `dm->length >= 0x30` below but the memory load already done here.
>> After reading thread_count2, it cannot be guaranteed that the data is valid.
>>
>> 'dm->length >= 0x30' can detect that thread_count2 is an available data,
>> right?
>>
> I mean you should perform the check before doing memory load.
It doesn't matter whether it's before or after.

Anyway, here it's just reading. Before it's actually used later,
it will check this length.
>>>    +       if (thread_count != 0)
>>>    +               loongson_sysconf.cores_per_package = dm->length >= 0x30 && thread_count == 0xFF ?
>>>    +                                                    thread_count2 : thread_count;
>>>
>>>            pr_info("CpuClock = %llu\n", cpu_clock_freq);
>>>     }
>>>    --
>>>    2.20.1