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] [day] [month] [year] [list]
Message-ID: <068cfd1c-8bf7-4123-8f23-49d9ec27de2e@amperemail.onmicrosoft.com>
Date: Tue, 16 Jan 2024 09:47:23 +0800
From: Shijie Huang <shijie@...eremail.onmicrosoft.com>
To: Mark Rutland <mark.rutland@....com>,
 Huang Shijie <shijie@...amperecomputing.com>
Cc: catalin.marinas@....com, patches@...erecomputing.com, will@...nel.org,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] arm64: implement arm64 specific cpu_to_node

Hi Mark,

在 2024/1/15 19:44, Mark Rutland 写道:
> On Mon, Jan 15, 2024 at 05:59:31PM +0800, Huang Shijie wrote:
>> After setting the right NUMA node for VMAP stack,
>>    https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?id=75b5e0bf90bf
>>
>> I found there are at least four places in the common code where
>> the cpu_to_node() is called before it is initialized:
>>     0.) early_trace_init()         in kernel/trace/trace.c
>>     1.) sched_init()               in kernel/sched/core.c
>>     2.) init_sched_fair_class()    in kernel/sched/fair.c
>>     3.) workqueue_init_early()     in kernel/workqueue.c
>>
>> We cannot use early_cpu_to_node() for them, since early_cpu_to_node()
>> does not work for some ARCHs, such as x86, riscv, etc.
> I spot that x86 seems to have an implementation of early_cpu_to_node(); what's
> wrong with it?

Yes, you are right. I check the code again, x86 has its own 
early_cpu_to_node().


>
>> So we have to implement the arm64 specific cpu_to_node().
> Surely those early uses of cpu_to_node() are equally broken on those other

yes. some ARCHs also has the same issue. But I am not sure if all ARCHs 
support the NUMA.


> architectures, so why should this be specific to arm64?

I just want to fix the arm64 first. :)

But if you think we should fix the common code firstly, I am okay.


>
>> This patch
>>     0.) introduces the __cpu_to_node function pointer,
>>         and exports it for kernel modules.
>>
>>     1.) defines a macro cpu_to_node to override the
>>         generic percpu implementation of cpu_to_node.
>>
>>     2.) __cpu_to_node is initialized with early_cpu_to_node() before
>>         numa_node is initialized.
>>
>>     3.) __cpu_to_node is set to arm64_cpu_to_node() when numa_node is ready.
>>        arm64_cpu_to_node() is a clone of the generic cpu_to_node().
> I don't think this is the right approach. Regardlesss of anything else, we
> shouldn't have a solution that only fixes arm64.
>
> Why can't we mandate an early_cpu_to_node(), and have the other architectures
> implement that?
>
> Why can't we change cpu_to_node() to automatically do the right thing?

ok, I will change the common code.


Thanks

Huang Shijie


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ