Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Will Deacon]

On Tue, Aug 23, 2016 at 07:19:01PM +0800, Leizhen (ThunderTown) wrote:
> He applied my patches, which I mentioned these days.

[...]

> I will update my patch series and resend it again.

To be clear, you plan to send an updated version of:

  [PATCH v6 00/14] fix some type infos and bugs for arm64/of numa

so I can ignore v6 of that?

Will

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Will Deacon]

On Tue, Aug 23, 2016 at 07:19:01PM +0800, Leizhen (ThunderTown) wrote:
> He applied my patches, which I mentioned these days.

[...]

> I will update my patch series and resend it again.

To be clear, you plan to send an updated version of:

  [PATCH v6 00/14] fix some type infos and bugs for arm64/of numa

so I can ignore v6 of that?

Will

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Leizhen (ThunderTown)]

On 2016/8/23 19:30, Will Deacon wrote:
> On Tue, Aug 23, 2016 at 07:19:01PM +0800, Leizhen (ThunderTown) wrote:
>> He applied my patches, which I mentioned these days.
> 
> [...]
> 
>> I will update my patch series and resend it again.
> 
> To be clear, you plan to send an updated version of:
Yes, but just merge Zhongjiang's patch into mine, only one or two lines changed.

> 
>   [PATCH v6 00/14] fix some type infos and bugs for arm64/of numa
> 
> so I can ignore v6 of that?
If you have not merged v6 into your branch, I think you can wait my v7. I will 
send v7 tomorrow.

> 
> Will
> 
> .
> 

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Leizhen (ThunderTown)]

On 2016/8/23 19:30, Will Deacon wrote:
> On Tue, Aug 23, 2016 at 07:19:01PM +0800, Leizhen (ThunderTown) wrote:
>> He applied my patches, which I mentioned these days.
> 
> [...]
> 
>> I will update my patch series and resend it again.
> 
> To be clear, you plan to send an updated version of:
Yes, but just merge Zhongjiang's patch into mine, only one or two lines changed.

> 
>   [PATCH v6 00/14] fix some type infos and bugs for arm64/of numa
> 
> so I can ignore v6 of that?
If you have not merged v6 into your branch, I think you can wait my v7. I will 
send v7 tomorrow.

> 
> Will
> 
> .
> 

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Leizhen (ThunderTown)]

On 2016/8/22 22:28, Catalin Marinas wrote:
> On Sat, Aug 20, 2016 at 05:38:59PM +0800, zhong jiang wrote:
>> On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
>>> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
>>>  wrote:
 On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>>  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.
> [...]
 --- 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]);
>> }
>
> The issue comes up when we test the kdump. it will leads to kernel crash.
> when I debug the issue, I find boot cpu actually bound to the node1. while
> node1 is not real existence when numa_off enable.

 boot cpu is default mapped to node0
 are you running with any other patches?
He applied my patches, which I mentioned these days.

I chated with ZhongJiang, this problem is only exist for my patches, and no 
matter
whether use kdump or not. Mainline doesn't have this problem.

The details of this problem is(suppose numa_off is true), according to the code 
execution sequence :

1. setup_arch-->bootmem_init-->arm64_numa_init
When numa_off is true, all memory blocks will add into node 0.

2. setup_arch-->of_smp_init_cpus
I added early_map_cpu_to_node for boot cpu, so that the nid of cpu0 will change 
to the value read from dt node.
With ZhongJiang's patch, it will correct the nid of cpu0 to zero when numa_off 
is true.

3. build_all_zonelists
Because numa is off, so that only the control block of node 0 had been 
initialized. So cpu0 with non-zero nid will lead the kernel crash.

4. kernel_init_freeable-->smp_prepare_cpus-->smp_store_cpu_info
Set the nid of cpu0 to zero, but it's too late.

5. secondary_start_kernel-->smp_store_cpu_info
Set the nid of other cpus to zero.

I will update my patch series and resend it again.

Best regards,
 Town·Thunder
 (My Chinese name Zhen Lei direct translation into English)

>>>
>>> if you added any patch to change this code
>>>   /* init boot processor */
>>> cpu_to_node_map[0] = 0;
>>> map_cpu_to_node(0, 0);
>>>
>>> then adding code to take-care numa_off here might solve your issue.
>>
>>  but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
>>  the relation node. and the node is from devicetree.
>>
>>  you points to the code will be covered with another node. therefore, it is
>>  possible that cpu_to_node[cpu] will leads to the incorrect results. 
>> therefore,
>>  The crash will come up.
> 
> I think I get Ganapat's point. The cpu_to_node_map[0] may be incorrectly
> set by early_map_cpu_to_node() when called from smp_init_cpus() ->
> of_parse_and_init_cpus(). However, the cpu_to_node_map[] array is *only*
> read by numa_store_cpu_info(). This latter function calls
> map_cpu_to_node() and, if numa_off, will only ever pass 0 as the nid.
> 
> Given that the cpu_to_node_map[] array is static, I don't see how any
> non-zero value could leak outside the arch/arm64/mm/numa.c file.
> 
> So please give more details of any additional patches you have on top of
> mainline or whether you reproduced this issue with the vanilla kernel
> (since you mentioned kdump, that's not in mainline yet).
> 

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Leizhen (ThunderTown)]

On 2016/8/22 22:28, Catalin Marinas wrote:
> On Sat, Aug 20, 2016 at 05:38:59PM +0800, zhong jiang wrote:
>> On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
>>> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
>>>  wrote:
 On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>>  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.
> [...]
 --- 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]);
>> }
>
> The issue comes up when we test the kdump. it will leads to kernel crash.
> when I debug the issue, I find boot cpu actually bound to the node1. while
> node1 is not real existence when numa_off enable.

 boot cpu is default mapped to node0
 are you running with any other patches?
He applied my patches, which I mentioned these days.

I chated with ZhongJiang, this problem is only exist for my patches, and no 
matter
whether use kdump or not. Mainline doesn't have this problem.

The details of this problem is(suppose numa_off is true), according to the code 
execution sequence :

1. setup_arch-->bootmem_init-->arm64_numa_init
When numa_off is true, all memory blocks will add into node 0.

2. setup_arch-->of_smp_init_cpus
I added early_map_cpu_to_node for boot cpu, so that the nid of cpu0 will change 
to the value read from dt node.
With ZhongJiang's patch, it will correct the nid of cpu0 to zero when numa_off 
is true.

3. build_all_zonelists
Because numa is off, so that only the control block of node 0 had been 
initialized. So cpu0 with non-zero nid will lead the kernel crash.

4. kernel_init_freeable-->smp_prepare_cpus-->smp_store_cpu_info
Set the nid of cpu0 to zero, but it's too late.

5. secondary_start_kernel-->smp_store_cpu_info
Set the nid of other cpus to zero.

I will update my patch series and resend it again.

Best regards,
 Town·Thunder
 (My Chinese name Zhen Lei direct translation into English)

>>>
>>> if you added any patch to change this code
>>>   /* init boot processor */
>>> cpu_to_node_map[0] = 0;
>>> map_cpu_to_node(0, 0);
>>>
>>> then adding code to take-care numa_off here might solve your issue.
>>
>>  but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
>>  the relation node. and the node is from devicetree.
>>
>>  you points to the code will be covered with another node. therefore, it is
>>  possible that cpu_to_node[cpu] will leads to the incorrect results. 
>> therefore,
>>  The crash will come up.
> 
> I think I get Ganapat's point. The cpu_to_node_map[0] may be incorrectly
> set by early_map_cpu_to_node() when called from smp_init_cpus() ->
> of_parse_and_init_cpus(). However, the cpu_to_node_map[] array is *only*
> read by numa_store_cpu_info(). This latter function calls
> map_cpu_to_node() and, if numa_off, will only ever pass 0 as the nid.
> 
> Given that the cpu_to_node_map[] array is static, I don't see how any
> non-zero value could leak outside the arch/arm64/mm/numa.c file.
> 
> So please give more details of any additional patches you have on top of
> mainline or whether you reproduced this issue with the vanilla kernel
> (since you mentioned kdump, that's not in mainline yet).
> 

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/22 22:28, Catalin Marinas wrote:
> On Sat, Aug 20, 2016 at 05:38:59PM +0800, zhong jiang wrote:
>> On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
>>> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
>>>  wrote:
 On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>>  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.
> [...]
 --- 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]);
>> }
> The issue comes up when we test the kdump. it will leads to kernel crash.
> when I debug the issue, I find boot cpu actually bound to the node1. while
> node1 is not real existence when numa_off enable.
 boot cpu is default mapped to node0
 are you running with any other patches?
>>> if you added any patch to change this code
>>>   /* init boot processor */
>>> cpu_to_node_map[0] = 0;
>>> map_cpu_to_node(0, 0);
>>>
>>> then adding code to take-care numa_off here might solve your issue.
>>  but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
>>  the relation node. and the node is from devicetree.
>>
>>  you points to the code will be covered with another node. therefore, it is
>>  possible that cpu_to_node[cpu] will leads to the incorrect results. 
>> therefore,
>>  The crash will come up.
> I think I get Ganapat's point. The cpu_to_node_map[0] may be incorrectly
> set by early_map_cpu_to_node() when called from smp_init_cpus() ->
> of_parse_and_init_cpus(). However, the cpu_to_node_map[] array is *only*
> read by numa_store_cpu_info(). This latter function calls
> map_cpu_to_node() and, if numa_off, will only ever pass 0 as the nid.
>
> Given that the cpu_to_node_map[] array is static, I don't see how any
> non-zero value could leak outside the arch/arm64/mm/numa.c file.
>
> So please give more details of any additional patches you have on top of
> mainline or whether you reproduced this issue with the vanilla kernel
> (since you mentioned kdump, that's not in mainline yet).
>
Thanks for Catalin and Ganapatral.
I am sorry for that.  The mainline have solved.  The mainline changes is too 
much, I did not notice.

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/22 22:28, Catalin Marinas wrote:
> On Sat, Aug 20, 2016 at 05:38:59PM +0800, zhong jiang wrote:
>> On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
>>> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
>>>  wrote:
 On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>>  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.
> [...]
 --- 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]);
>> }
> The issue comes up when we test the kdump. it will leads to kernel crash.
> when I debug the issue, I find boot cpu actually bound to the node1. while
> node1 is not real existence when numa_off enable.
 boot cpu is default mapped to node0
 are you running with any other patches?
>>> if you added any patch to change this code
>>>   /* init boot processor */
>>> cpu_to_node_map[0] = 0;
>>> map_cpu_to_node(0, 0);
>>>
>>> then adding code to take-care numa_off here might solve your issue.
>>  but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
>>  the relation node. and the node is from devicetree.
>>
>>  you points to the code will be covered with another node. therefore, it is
>>  possible that cpu_to_node[cpu] will leads to the incorrect results. 
>> therefore,
>>  The crash will come up.
> I think I get Ganapat's point. The cpu_to_node_map[0] may be incorrectly
> set by early_map_cpu_to_node() when called from smp_init_cpus() ->
> of_parse_and_init_cpus(). However, the cpu_to_node_map[] array is *only*
> read by numa_store_cpu_info(). This latter function calls
> map_cpu_to_node() and, if numa_off, will only ever pass 0 as the nid.
>
> Given that the cpu_to_node_map[] array is static, I don't see how any
> non-zero value could leak outside the arch/arm64/mm/numa.c file.
>
> So please give more details of any additional patches you have on top of
> mainline or whether you reproduced this issue with the vanilla kernel
> (since you mentioned kdump, that's not in mainline yet).
>
Thanks for Catalin and Ganapatral.
I am sorry for that.  The mainline have solved.  The mainline changes is too 
much, I did not notice.

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Catalin Marinas]

On Sat, Aug 20, 2016 at 05:38:59PM +0800, zhong jiang wrote:
> On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
> > On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
> >  wrote:
> >> On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
> >>> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>  On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>   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.
[...]
> >> --- 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]);
>  }
> >>>
> >>> The issue comes up when we test the kdump. it will leads to kernel crash.
> >>> when I debug the issue, I find boot cpu actually bound to the node1. while
> >>> node1 is not real existence when numa_off enable.
> >>
> >> boot cpu is default mapped to node0
> >> are you running with any other patches?
> >
> > if you added any patch to change this code
> >   /* init boot processor */
> > cpu_to_node_map[0] = 0;
> > map_cpu_to_node(0, 0);
> >
> > then adding code to take-care numa_off here might solve your issue.
> 
>  but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
>  the relation node. and the node is from devicetree.
> 
>  you points to the code will be covered with another node. therefore, it is
>  possible that cpu_to_node[cpu] will leads to the incorrect results. 
> therefore,
>  The crash will come up.

I think I get Ganapat's point. The cpu_to_node_map[0] may be incorrectly
set by early_map_cpu_to_node() when called from smp_init_cpus() ->
of_parse_and_init_cpus(). However, the cpu_to_node_map[] array is *only*
read by numa_store_cpu_info(). This latter function calls
map_cpu_to_node() and, if numa_off, will only ever pass 0 as the nid.

Given that the cpu_to_node_map[] array is static, I don't see how any
non-zero value could leak outside the arch/arm64/mm/numa.c file.

So please give more details of any additional patches you have on top of
mainline or whether you reproduced this issue with the vanilla kernel
(since you mentioned kdump, that's not in mainline yet).

-- 
Catalin

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Catalin Marinas]

On Sat, Aug 20, 2016 at 05:38:59PM +0800, zhong jiang wrote:
> On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
> > On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
> >  wrote:
> >> On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
> >>> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>  On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>   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.
[...]
> >> --- 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]);
>  }
> >>>
> >>> The issue comes up when we test the kdump. it will leads to kernel crash.
> >>> when I debug the issue, I find boot cpu actually bound to the node1. while
> >>> node1 is not real existence when numa_off enable.
> >>
> >> boot cpu is default mapped to node0
> >> are you running with any other patches?
> >
> > if you added any patch to change this code
> >   /* init boot processor */
> > cpu_to_node_map[0] = 0;
> > map_cpu_to_node(0, 0);
> >
> > then adding code to take-care numa_off here might solve your issue.
> 
>  but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
>  the relation node. and the node is from devicetree.
> 
>  you points to the code will be covered with another node. therefore, it is
>  possible that cpu_to_node[cpu] will leads to the incorrect results. 
> therefore,
>  The crash will come up.

I think I get Ganapat's point. The cpu_to_node_map[0] may be incorrectly
set by early_map_cpu_to_node() when called from smp_init_cpus() ->
of_parse_and_init_cpus(). However, the cpu_to_node_map[] array is *only*
read by numa_store_cpu_info(). This latter function calls
map_cpu_to_node() and, if numa_off, will only ever pass 0 as the nid.

Given that the cpu_to_node_map[] array is static, I don't see how any
non-zero value could leak outside the arch/arm64/mm/numa.c file.

So please give more details of any additional patches you have on top of
mainline or whether you reproduced this issue with the vanilla kernel
(since you mentioned kdump, that's not in mainline yet).

-- 
Catalin

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
>  wrote:
>> On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
>>> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
 On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
  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 
>> ---
>>  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
>>> The issue comes up when we test the kdump. it will leads to kernel crash.
>>> when I debug the issue, I find boot cpu actually bound to the node1. while
>>> node1 is not real existence when numa_off enable.
>> boot cpu is default mapped to node0
>> are you running with any other patches?
> if you added any patch to change this code
>   /* init boot processor */
> cpu_to_node_map[0] = 0;
> map_cpu_to_node(0, 0);
>
> then adding code to take-care numa_off here might solve your issue.
 but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
 the relation node. and the node is from devicetree.

 you points to the code will be covered with another node. therefore, it is
 possible that cpu_to_node[cpu] will leads to the incorrect results. therefore,
 The crash will come up.
>>> __build_all_zonelists will call the cpu_to_node[cpu], but orresponding 
>>> relation
>>> will be obtained from the devicetree. therefore, the issue will come up.
>> when numa_off, all cpus are mapped to node0( refer
>> numa_store_cpu_info) and device tree mapping is ignored.
>>> The corresponding message is as follows when kdump start. it is obvious 
>>> that mem
>>> range points to the node1 in the devicetree.
>>>
>>> Early memory node ranges
>>> node   0: [mem 0x005fe000-0x005f]
>>> Initmem setup node 0 [mem 0x005fe000-0x005f]
>>>
>>> Unable to handle kernel paging request at virtual address 1690
>>> pgd = 81226000
>>> [1690] *pgd=
>>> Internal error: Oops: 9604 [#1] SMP
>>>  Modules linked in:
>>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
>>> Hardware name: Hisilicon Hi1612 Development Board (DT)
>>>  task: 8102b730 ti: 81018000 task.ti: 81018000
>>> PC is at next_zones_zonelist+0x18/0x80
>>>  LR is at __build_all_zonelists+0x1e0/0x288
>>> 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
>>   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-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 .

>>>
> .
>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/19 12:11, Ganapatrao Kulkarni wrote:
> On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
>  wrote:
>> On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
>>> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
 On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
  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 
>> ---
>>  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
>>> The issue comes up when we test the kdump. it will leads to kernel crash.
>>> when I debug the issue, I find boot cpu actually bound to the node1. while
>>> node1 is not real existence when numa_off enable.
>> boot cpu is default mapped to node0
>> are you running with any other patches?
> if you added any patch to change this code
>   /* init boot processor */
> cpu_to_node_map[0] = 0;
> map_cpu_to_node(0, 0);
>
> then adding code to take-care numa_off here might solve your issue.
 but in of_smp_init_cpus, boot cpu will call early_map_cpu_to_node[] to get
 the relation node. and the node is from devicetree.

 you points to the code will be covered with another node. therefore, it is
 possible that cpu_to_node[cpu] will leads to the incorrect results. therefore,
 The crash will come up.
>>> __build_all_zonelists will call the cpu_to_node[cpu], but orresponding 
>>> relation
>>> will be obtained from the devicetree. therefore, the issue will come up.
>> when numa_off, all cpus are mapped to node0( refer
>> numa_store_cpu_info) and device tree mapping is ignored.
>>> The corresponding message is as follows when kdump start. it is obvious 
>>> that mem
>>> range points to the node1 in the devicetree.
>>>
>>> Early memory node ranges
>>> node   0: [mem 0x005fe000-0x005f]
>>> Initmem setup node 0 [mem 0x005fe000-0x005f]
>>>
>>> Unable to handle kernel paging request at virtual address 1690
>>> pgd = 81226000
>>> [1690] *pgd=
>>> Internal error: Oops: 9604 [#1] SMP
>>>  Modules linked in:
>>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
>>> Hardware name: Hisilicon Hi1612 Development Board (DT)
>>>  task: 8102b730 ti: 81018000 task.ti: 81018000
>>> PC is at next_zones_zonelist+0x18/0x80
>>>  LR is at __build_all_zonelists+0x1e0/0x288
>>> 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
>>   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-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
 .

>>>
> .
>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Ganapatrao Kulkarni]

On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>>  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 
 ---
  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
> The issue comes up when we test the kdump. it will leads to kernel crash.
> when I debug the issue, I find boot cpu actually bound to the node1. while
> node1 is not real existence when numa_off enable.

boot cpu is default mapped to node0
are you running with any other patches?
>
> __build_all_zonelists will call the cpu_to_node[cpu], but orresponding 
> relation
> will be obtained from the devicetree. therefore, the issue will come up.

when numa_off, all cpus are mapped to node0( refer
numa_store_cpu_info) and device tree mapping is ignored.
> The corresponding message is as follows when kdump start. it is obvious that 
> mem
> range points to the node1 in the devicetree.
>
> Early memory node ranges
> node   0: [mem 0x005fe000-0x005f]
> Initmem setup node 0 [mem 0x005fe000-0x005f]
>
> Unable to handle kernel paging request at virtual address 1690
> pgd = 81226000
> [1690] *pgd=
> Internal error: Oops: 9604 [#1] SMP
>  Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
> Hardware name: Hisilicon Hi1612 Development Board (DT)
>  task: 8102b730 ti: 81018000 task.ti: 81018000
> PC is at next_zones_zonelist+0x18/0x80
>  LR is at __build_all_zonelists+0x1e0/0x288
> 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
   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-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> .
>>
>
>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Ganapatrao Kulkarni]

On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>>  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 
 ---
  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
> The issue comes up when we test the kdump. it will leads to kernel crash.
> when I debug the issue, I find boot cpu actually bound to the node1. while
> node1 is not real existence when numa_off enable.

boot cpu is default mapped to node0
are you running with any other patches?
>
> __build_all_zonelists will call the cpu_to_node[cpu], but orresponding 
> relation
> will be obtained from the devicetree. therefore, the issue will come up.

when numa_off, all cpus are mapped to node0( refer
numa_store_cpu_info) and device tree mapping is ignored.
> The corresponding message is as follows when kdump start. it is obvious that 
> mem
> range points to the node1 in the devicetree.
>
> Early memory node ranges
> node   0: [mem 0x005fe000-0x005f]
> Initmem setup node 0 [mem 0x005fe000-0x005f]
>
> Unable to handle kernel paging request at virtual address 1690
> pgd = 81226000
> [1690] *pgd=
> Internal error: Oops: 9604 [#1] SMP
>  Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
> Hardware name: Hisilicon Hi1612 Development Board (DT)
>  task: 8102b730 ti: 81018000 task.ti: 81018000
> PC is at next_zones_zonelist+0x18/0x80
>  LR is at __build_all_zonelists+0x1e0/0x288
> 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
   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-ker...@lists.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>> .
>>
>
>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Ganapatrao Kulkarni]

On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
 wrote:
> On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
>> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>>> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>>>  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 
> ---
>  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
>> The issue comes up when we test the kdump. it will leads to kernel crash.
>> when I debug the issue, I find boot cpu actually bound to the node1. while
>> node1 is not real existence when numa_off enable.
>
> boot cpu is default mapped to node0
> are you running with any other patches?

if you added any patch to change this code
  /* init boot processor */
cpu_to_node_map[0] = 0;
map_cpu_to_node(0, 0);

then adding code to take-care numa_off here might solve your issue.

>>
>> __build_all_zonelists will call the cpu_to_node[cpu], but orresponding 
>> relation
>> will be obtained from the devicetree. therefore, the issue will come up.
>
> when numa_off, all cpus are mapped to node0( refer
> numa_store_cpu_info) and device tree mapping is ignored.
>> The corresponding message is as follows when kdump start. it is obvious that 
>> mem
>> range points to the node1 in the devicetree.
>>
>> Early memory node ranges
>> node   0: [mem 0x005fe000-0x005f]
>> Initmem setup node 0 [mem 0x005fe000-0x005f]
>>
>> Unable to handle kernel paging request at virtual address 1690
>> pgd = 81226000
>> [1690] *pgd=
>> Internal error: Oops: 9604 [#1] SMP
>>  Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
>> Hardware name: Hisilicon Hi1612 Development Board (DT)
>>  task: 8102b730 ti: 81018000 task.ti: 81018000
>> PC is at next_zones_zonelist+0x18/0x80
>>  LR is at __build_all_zonelists+0x1e0/0x288
>> 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
>   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-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>> .
>>>
>>
>>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Ganapatrao Kulkarni]

On Fri, Aug 19, 2016 at 9:30 AM, Ganapatrao Kulkarni
 wrote:
> On Fri, Aug 19, 2016 at 7:28 AM, zhong jiang  wrote:
>> On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
>>> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>>>  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 
> ---
>  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
>> The issue comes up when we test the kdump. it will leads to kernel crash.
>> when I debug the issue, I find boot cpu actually bound to the node1. while
>> node1 is not real existence when numa_off enable.
>
> boot cpu is default mapped to node0
> are you running with any other patches?

if you added any patch to change this code
  /* init boot processor */
cpu_to_node_map[0] = 0;
map_cpu_to_node(0, 0);

then adding code to take-care numa_off here might solve your issue.

>>
>> __build_all_zonelists will call the cpu_to_node[cpu], but orresponding 
>> relation
>> will be obtained from the devicetree. therefore, the issue will come up.
>
> when numa_off, all cpus are mapped to node0( refer
> numa_store_cpu_info) and device tree mapping is ignored.
>> The corresponding message is as follows when kdump start. it is obvious that 
>> mem
>> range points to the node1 in the devicetree.
>>
>> Early memory node ranges
>> node   0: [mem 0x005fe000-0x005f]
>> Initmem setup node 0 [mem 0x005fe000-0x005f]
>>
>> Unable to handle kernel paging request at virtual address 1690
>> pgd = 81226000
>> [1690] *pgd=
>> Internal error: Oops: 9604 [#1] SMP
>>  Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
>> Hardware name: Hisilicon Hi1612 Development Board (DT)
>>  task: 8102b730 ti: 81018000 task.ti: 81018000
>> PC is at next_zones_zonelist+0x18/0x80
>>  LR is at __build_all_zonelists+0x1e0/0x288
>> 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
>   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-ker...@lists.infradead.org
 http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>> .
>>>
>>
>>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Ganapatrao Kulkarni]

On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
 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 
>> ---
>>  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-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Ganapatrao Kulkarni]

On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
 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 
>> ---
>>  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-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>  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 
>>> ---
>>>  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
The issue comes up when we test the kdump. it will leads to kernel crash.
when I debug the issue, I find boot cpu actually bound to the node1. while
node1 is not real existence when numa_off enable.

__build_all_zonelists will call the cpu_to_node[cpu], but orresponding relation
will be obtained from the devicetree. therefore, the issue will come up.
The corresponding message is as follows when kdump start. it is obvious that mem
range points to the node1 in the devicetree.

Early memory node ranges
node   0: [mem 0x005fe000-0x005f]
Initmem setup node 0 [mem 0x005fe000-0x005f]

Unable to handle kernel paging request at virtual address 1690
pgd = 81226000
[1690] *pgd=
Internal error: Oops: 9604 [#1] SMP
 Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
Hardware name: Hisilicon Hi1612 Development Board (DT)
 task: 8102b730 ti: 81018000 task.ti: 81018000
PC is at next_zones_zonelist+0x18/0x80
 LR is at __build_all_zonelists+0x1e0/0x288
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
>>>   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-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> .
>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>  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 
>>> ---
>>>  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
The issue comes up when we test the kdump. it will leads to kernel crash.
when I debug the issue, I find boot cpu actually bound to the node1. while
node1 is not real existence when numa_off enable.

__build_all_zonelists will call the cpu_to_node[cpu], but orresponding relation
will be obtained from the devicetree. therefore, the issue will come up.
The corresponding message is as follows when kdump start. it is obvious that mem
range points to the node1 in the devicetree.

Early memory node ranges
node   0: [mem 0x005fe000-0x005f]
Initmem setup node 0 [mem 0x005fe000-0x005f]

Unable to handle kernel paging request at virtual address 1690
pgd = 81226000
[1690] *pgd=
Internal error: Oops: 9604 [#1] SMP
 Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
Hardware name: Hisilicon Hi1612 Development Board (DT)
 task: 8102b730 ti: 81018000 task.ti: 81018000
PC is at next_zones_zonelist+0x18/0x80
 LR is at __build_all_zonelists+0x1e0/0x288
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
>>>   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-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> .
>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>  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?
yes, it will leads to kernel crash. the details is as follows.
 
Unable to handle kernel paging request at virtual address 1690
pgd = 81226000
[1690] *pgd=
Internal error: Oops: 9604 [#1] SMP
 Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
Hardware name: Hisilicon Hi1612 Development Board (DT)
 task: 8102b730 ti: 81018000 task.ti: 81018000
PC is at next_zones_zonelist+0x18/0x80
 LR is at __build_all_zonelists+0x1e0/0x288
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
>>> The patch fix it by fallback to node 0. therefore, the cpu will bound to 
>>> the node
>>> correctly.
>>>
>>> Signed-off-by: zhongjiang 
>>> ---
>>>  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-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> .
>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[zhong jiang]

On 2016/8/19 1:45, Ganapatrao Kulkarni wrote:
> On Thu, Aug 18, 2016 at 9:34 PM, Catalin Marinas
>  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?
yes, it will leads to kernel crash. the details is as follows.
 
Unable to handle kernel paging request at virtual address 1690
pgd = 81226000
[1690] *pgd=
Internal error: Oops: 9604 [#1] SMP
 Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 4.1.27-vhulk3.6.5.aarch64 #1
Hardware name: Hisilicon Hi1612 Development Board (DT)
 task: 8102b730 ti: 81018000 task.ti: 81018000
PC is at next_zones_zonelist+0x18/0x80
 LR is at __build_all_zonelists+0x1e0/0x288
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
>>> The patch fix it by fallback to node 0. therefore, the cpu will bound to 
>>> the node
>>> correctly.
>>>
>>> Signed-off-by: zhongjiang 
>>> ---
>>>  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-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> .
>

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Catalin Marinas]

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

Re: [PATCH] mm, numa: boot cpu should bound to the node0 when node_off enable

[Catalin Marinas]

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