Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC

2021-03-24 Thread John Paul Adrian Glaubitz
Hi Andrew!

On 3/24/21 11:39 PM, Andrew Morton wrote:
> On Wed, 24 Mar 2021 11:20:45 +0100 John Paul Adrian Glaubitz 
>  wrote:
> 
 #NEXT_PATCHES_START mainline-later (next week, approximately)
 ia64-mca-allocate-early-mca-with-gfp_atomic.patch
>>
>> Great, thanks. We're still missing Valentin's patch for the NUMA enumeration 
>> issue
>> though. Should Valentin send the patch again with Andrew CC'ed?
> 
> I subscribed to linux-ia64 today, so I can go in there to find things. 

Good to know, thanks.

> But if there's anything presently outstanding, please do resend.
> 
> I presently have
> 
> module-remove-duplicate-include-in-arch-ia64-kernel-heads.patch
> ia64-kernel-few-typos-fixed-in-the-file-fsyss.patch
> ia64-include-asm-minor-typo-fixes-in-the-file-pgtableh.patch
> ia64-ensure-proper-numa-distance-and-possible-map-initialization.patch
> ia64-drop-unused-ia64_fw_emu-ifdef.patch

I send two patches today which fix two ia64-related build issues in tools,
not sure whether you should pick those as well or I should just wait for
the maintainers that get_maintainers.pl report to answer.

> https://marc.info/?l=linux-netdev=161652285123466=2
> https://marc.info/?l=linux-netdev=161652400124112=2

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC

2021-03-24 Thread Andrew Morton
On Wed, 24 Mar 2021 11:20:45 +0100 John Paul Adrian Glaubitz 
 wrote:

> >> #NEXT_PATCHES_START mainline-later (next week, approximately)
> >> ia64-mca-allocate-early-mca-with-gfp_atomic.patch
> 
> Great, thanks. We're still missing Valentin's patch for the NUMA enumeration 
> issue
> though. Should Valentin send the patch again with Andrew CC'ed?

I subscribed to linux-ia64 today, so I can go in there to find things. 
But if there's anything presently outstanding, please do resend.

I presently have

module-remove-duplicate-include-in-arch-ia64-kernel-heads.patch
ia64-kernel-few-typos-fixed-in-the-file-fsyss.patch
ia64-include-asm-minor-typo-fixes-in-the-file-pgtableh.patch
ia64-ensure-proper-numa-distance-and-possible-map-initialization.patch
ia64-drop-unused-ia64_fw_emu-ifdef.patch



Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC

2021-03-24 Thread John Paul Adrian Glaubitz
Hi Sergei!

On 3/23/21 6:47 PM, Sergei Trofimovich wrote:
> On Tue, 23 Mar 2021 16:15:06 +0100
> John Paul Adrian Glaubitz  wrote:
> 
>> Hi Andrew!
>>
>> On 3/15/21 9:50 AM, Sergei Trofimovich wrote:
>>> The sleep warning happens at early boot right at
>>> secondary CPU activation bootup:
>>>
>>> smp: Bringing up secondary CPUs ...
>>> BUG: sleeping function called from invalid context at 
>>> mm/page_alloc.c:4942
>>> in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: 
>>> swapper/1
>>> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
>>> 5.12.0-rc2-7-g79e228d0b611-dirty #99
>>>
>>> Call Trace:
>>>  [] show_stack+0x90/0xc0
>>>  [] dump_stack+0x150/0x1c0
>>>  [] ___might_sleep+0x1c0/0x2a0
>>>  [] __might_sleep+0xa0/0x160
>>>  [] __alloc_pages_nodemask+0x1a0/0x600
>>>  [] alloc_page_interleave+0x30/0x1c0
>>>  [] alloc_pages_current+0x2c0/0x340
>>>  [] __get_free_pages+0x30/0xa0
>>>  [] ia64_mca_cpu_init+0x2d0/0x3a0
>>>  [] cpu_init+0x8b0/0x1440
>>>  [] start_secondary+0x60/0x700
>>>  [] start_ap+0x750/0x780
>>> Fixed BSP b0 value from CPU 1
>>>
>>> As I understand interrupts are not enabled yet and system has a lot
>>> of memory. There is little chance to sleep and switch to GFP_ATOMIC
>>> should be a no-op.
>>>
>>> CC: Andrew Morton 
>>> CC: linux-i...@vger.kernel.org
>>> Signed-off-by: Sergei Trofimovich 
>>> ---
>>>  arch/ia64/kernel/mca.c | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
>>> index d4cae2fc69ca..adf6521525f4 100644
>>> --- a/arch/ia64/kernel/mca.c
>>> +++ b/arch/ia64/kernel/mca.c
>>> @@ -1824,7 +1824,7 @@ ia64_mca_cpu_init(void *cpu_data)
>>> data = mca_bootmem();
>>> first_time = 0;
>>> } else
>>> -   data = (void *)__get_free_pages(GFP_KERNEL,
>>> +   data = (void *)__get_free_pages(GFP_ATOMIC,
>>> get_order(sz));
>>> if (!data)
>>> panic("Could not allocate MCA memory for cpu %d\n",
>>>   
>>
>> Has this one been picked up for your tree already?
> 
> Should be there: https://www.ozlabs.org/~akpm/mmotm/series
> 
>> #NEXT_PATCHES_START mainline-later (next week, approximately)
>> ia64-mca-allocate-early-mca-with-gfp_atomic.patch

Great, thanks. We're still missing Valentin's patch for the NUMA enumeration 
issue
though. Should Valentin send the patch again with Andrew CC'ed?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC

2021-03-23 Thread Sergei Trofimovich
On Tue, 23 Mar 2021 16:15:06 +0100
John Paul Adrian Glaubitz  wrote:

> Hi Andrew!
> 
> On 3/15/21 9:50 AM, Sergei Trofimovich wrote:
> > The sleep warning happens at early boot right at
> > secondary CPU activation bootup:
> > 
> > smp: Bringing up secondary CPUs ...
> > BUG: sleeping function called from invalid context at 
> > mm/page_alloc.c:4942
> > in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: 
> > swapper/1
> > CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> > 5.12.0-rc2-7-g79e228d0b611-dirty #99
> > 
> > Call Trace:
> >  [] show_stack+0x90/0xc0
> >  [] dump_stack+0x150/0x1c0
> >  [] ___might_sleep+0x1c0/0x2a0
> >  [] __might_sleep+0xa0/0x160
> >  [] __alloc_pages_nodemask+0x1a0/0x600
> >  [] alloc_page_interleave+0x30/0x1c0
> >  [] alloc_pages_current+0x2c0/0x340
> >  [] __get_free_pages+0x30/0xa0
> >  [] ia64_mca_cpu_init+0x2d0/0x3a0
> >  [] cpu_init+0x8b0/0x1440
> >  [] start_secondary+0x60/0x700
> >  [] start_ap+0x750/0x780
> > Fixed BSP b0 value from CPU 1
> > 
> > As I understand interrupts are not enabled yet and system has a lot
> > of memory. There is little chance to sleep and switch to GFP_ATOMIC
> > should be a no-op.
> > 
> > CC: Andrew Morton 
> > CC: linux-i...@vger.kernel.org
> > Signed-off-by: Sergei Trofimovich 
> > ---
> >  arch/ia64/kernel/mca.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
> > index d4cae2fc69ca..adf6521525f4 100644
> > --- a/arch/ia64/kernel/mca.c
> > +++ b/arch/ia64/kernel/mca.c
> > @@ -1824,7 +1824,7 @@ ia64_mca_cpu_init(void *cpu_data)
> > data = mca_bootmem();
> > first_time = 0;
> > } else
> > -   data = (void *)__get_free_pages(GFP_KERNEL,
> > +   data = (void *)__get_free_pages(GFP_ATOMIC,
> > get_order(sz));
> > if (!data)
> > panic("Could not allocate MCA memory for cpu %d\n",
> >   
> 
> Has this one been picked up for your tree already?

Should be there: https://www.ozlabs.org/~akpm/mmotm/series

> #NEXT_PATCHES_START mainline-later (next week, approximately)
> ia64-mca-allocate-early-mca-with-gfp_atomic.patch


-- 

  Sergei


Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC

2021-03-23 Thread John Paul Adrian Glaubitz
Hi Andrew!

On 3/15/21 9:50 AM, Sergei Trofimovich wrote:
> The sleep warning happens at early boot right at
> secondary CPU activation bootup:
> 
> smp: Bringing up secondary CPUs ...
> BUG: sleeping function called from invalid context at mm/page_alloc.c:4942
> in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1
> CPU: 1 PID: 0 Comm: swapper/1 Not tainted 
> 5.12.0-rc2-7-g79e228d0b611-dirty #99
> 
> Call Trace:
>  [] show_stack+0x90/0xc0
>  [] dump_stack+0x150/0x1c0
>  [] ___might_sleep+0x1c0/0x2a0
>  [] __might_sleep+0xa0/0x160
>  [] __alloc_pages_nodemask+0x1a0/0x600
>  [] alloc_page_interleave+0x30/0x1c0
>  [] alloc_pages_current+0x2c0/0x340
>  [] __get_free_pages+0x30/0xa0
>  [] ia64_mca_cpu_init+0x2d0/0x3a0
>  [] cpu_init+0x8b0/0x1440
>  [] start_secondary+0x60/0x700
>  [] start_ap+0x750/0x780
> Fixed BSP b0 value from CPU 1
> 
> As I understand interrupts are not enabled yet and system has a lot
> of memory. There is little chance to sleep and switch to GFP_ATOMIC
> should be a no-op.
> 
> CC: Andrew Morton 
> CC: linux-i...@vger.kernel.org
> Signed-off-by: Sergei Trofimovich 
> ---
>  arch/ia64/kernel/mca.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
> index d4cae2fc69ca..adf6521525f4 100644
> --- a/arch/ia64/kernel/mca.c
> +++ b/arch/ia64/kernel/mca.c
> @@ -1824,7 +1824,7 @@ ia64_mca_cpu_init(void *cpu_data)
>   data = mca_bootmem();
>   first_time = 0;
>   } else
> - data = (void *)__get_free_pages(GFP_KERNEL,
> + data = (void *)__get_free_pages(GFP_ATOMIC,
>   get_order(sz));
>   if (!data)
>   panic("Could not allocate MCA memory for cpu %d\n",
> 

Has this one been picked up for your tree already?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913