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:   Thu, 18 Aug 2016 23:15:41 +0530
From:   Ganapatrao Kulkarni <gpkulkarni@...il.com>
To:     Catalin Marinas <catalin.marinas@....com>
Cc:     zhongjiang <zhongjiang@...wei.com>,
        Mark Rutland <mark.rutland@....com>,
        Will Deacon <will.deacon@....com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Ganapatrao Kulkarni <gkulkarni@...iumnetworks.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] mm, numa: boot cpu should bound to the node0 when
 node_off enable

On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
<catalin.marinas@....com> wrote:
> On Thu, Aug 18, 2016 at 09:09:26PM +0800, zhongjiang wrote:
>> At present, boot cpu will bound to a node from device tree when node_off enable.
>> if the node is not initialization, it will lead to a following problem.
>>
>>  next_zones_zonelist+0x18/0x80
>>  __build_all_zonelists+0x1e0/0x288
>>  build_all_zonelists_init+0x10/0x1c
>>  build_all_zonelists+0x114/0x128
>>  start_kernel+0x1a0/0x414
>
> I think this "problem" is missing a lot of information. Is this supposed
> to be a kernel panic?
>
>> The patch fix it by fallback to node 0. therefore, the cpu will bound to the node
>> correctly.
>>
>> Signed-off-by: zhongjiang <zhongjiang@...wei.com>
>> ---
>>  arch/arm64/mm/numa.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
>> index 4dcd7d6..1f8f5da 100644
>> --- a/arch/arm64/mm/numa.c
>> +++ b/arch/arm64/mm/numa.c
>> @@ -119,7 +119,7 @@ void numa_store_cpu_info(unsigned int cpu)
>>  void __init early_map_cpu_to_node(unsigned int cpu, int nid)
>>  {
>>       /* fallback to node 0 */
>> -     if (nid < 0 || nid >= MAX_NUMNODES)
>> +     if (nid < 0 || nid >= MAX_NUMNODES || numa_off)

i  did not understood how this line change fixes the issue that you
have mentioned (i too not understood fully the issue description)
this array used while mapping node id when secondary cores comes up
when numa_off is set the cpu_to_node_map[cpu] is not used and set to
node0 always( refer function numa_store_cpu_info)..
please provide more details to understand the issue you are facing.
/*
 *  Set the cpu to node and mem mapping
 */
void numa_store_cpu_info(unsigned int cpu)
{
        map_cpu_to_node(cpu, numa_off ? 0 : cpu_to_node_map[cpu]);
}

thanks
Ganapat
>>               nid = 0;
>>
>>       cpu_to_node_map[cpu] = nid;
>
> The patch looks fine (slight inconsistence from the map_cpu_to_node()
> callers but I guess we don't want to expose numa_off outside this file).
> I would however like to see an Ack from Ganapat (cc'ed).
>
> --
> Catalin
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ