All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
@ 2021-03-15  8:50 Sergei Trofimovich
  2021-03-23 15:15   ` John Paul Adrian Glaubitz
  0 siblings, 1 reply; 10+ messages in thread
From: Sergei Trofimovich @ 2021-03-15  8:50 UTC (permalink / raw)
  To: Andrew Morton, linux-kernel; +Cc: Sergei Trofimovich, linux-ia64

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-00007-g79e228d0b611-dirty #99

    Call Trace:
     [<a000000100014d10>] show_stack+0x90/0xc0
     [<a000000101111d90>] dump_stack+0x150/0x1c0
     [<a0000001000cbec0>] ___might_sleep+0x1c0/0x2a0
     [<a0000001000cc040>] __might_sleep+0xa0/0x160
     [<a000000100399960>] __alloc_pages_nodemask+0x1a0/0x600
     [<a0000001003b71b0>] alloc_page_interleave+0x30/0x1c0
     [<a0000001003b9b60>] alloc_pages_current+0x2c0/0x340
     [<a00000010038c270>] __get_free_pages+0x30/0xa0
     [<a000000100044730>] ia64_mca_cpu_init+0x2d0/0x3a0
     [<a000000100023430>] cpu_init+0x8b0/0x1440
     [<a000000100054680>] start_secondary+0x60/0x700
     [<a00000010111e1d0>] 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 <akpm@linux-foundation.org>
CC: linux-ia64@vger.kernel.org
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
---
 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",
-- 
2.30.2


^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
  2021-03-15  8:50 [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC Sergei Trofimovich
@ 2021-03-23 15:15   ` John Paul Adrian Glaubitz
  0 siblings, 0 replies; 10+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-03-23 15:15 UTC (permalink / raw)
  To: Sergei Trofimovich, Andrew Morton, linux-kernel; +Cc: linux-ia64

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-00007-g79e228d0b611-dirty #99
> 
>     Call Trace:
>      [<a000000100014d10>] show_stack+0x90/0xc0
>      [<a000000101111d90>] dump_stack+0x150/0x1c0
>      [<a0000001000cbec0>] ___might_sleep+0x1c0/0x2a0
>      [<a0000001000cc040>] __might_sleep+0xa0/0x160
>      [<a000000100399960>] __alloc_pages_nodemask+0x1a0/0x600
>      [<a0000001003b71b0>] alloc_page_interleave+0x30/0x1c0
>      [<a0000001003b9b60>] alloc_pages_current+0x2c0/0x340
>      [<a00000010038c270>] __get_free_pages+0x30/0xa0
>      [<a000000100044730>] ia64_mca_cpu_init+0x2d0/0x3a0
>      [<a000000100023430>] cpu_init+0x8b0/0x1440
>      [<a000000100054680>] start_secondary+0x60/0x700
>      [<a00000010111e1d0>] 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 <akpm@linux-foundation.org>
> CC: linux-ia64@vger.kernel.org
> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
> ---
>  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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
@ 2021-03-23 15:15   ` John Paul Adrian Glaubitz
  0 siblings, 0 replies; 10+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-03-23 15:15 UTC (permalink / raw)
  To: Sergei Trofimovich, Andrew Morton, linux-kernel; +Cc: linux-ia64

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-00007-g79e228d0b611-dirty #99
> 
>     Call Trace:
>      [<a000000100014d10>] show_stack+0x90/0xc0
>      [<a000000101111d90>] dump_stack+0x150/0x1c0
>      [<a0000001000cbec0>] ___might_sleep+0x1c0/0x2a0
>      [<a0000001000cc040>] __might_sleep+0xa0/0x160
>      [<a000000100399960>] __alloc_pages_nodemask+0x1a0/0x600
>      [<a0000001003b71b0>] alloc_page_interleave+0x30/0x1c0
>      [<a0000001003b9b60>] alloc_pages_current+0x2c0/0x340
>      [<a00000010038c270>] __get_free_pages+0x30/0xa0
>      [<a000000100044730>] ia64_mca_cpu_init+0x2d0/0x3a0
>      [<a000000100023430>] cpu_init+0x8b0/0x1440
>      [<a000000100054680>] start_secondary+0x60/0x700
>      [<a00000010111e1d0>] 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 <akpm@linux-foundation.org>
> CC: linux-ia64@vger.kernel.org
> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
> ---
>  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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
  2021-03-23 15:15   ` John Paul Adrian Glaubitz
  (?)
@ 2021-03-23 17:47   ` Sergei Trofimovich
  2021-03-24 10:20       ` John Paul Adrian Glaubitz
  -1 siblings, 1 reply; 10+ messages in thread
From: Sergei Trofimovich @ 2021-03-23 17:47 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz; +Cc: Andrew Morton, linux-kernel, linux-ia64

On Tue, 23 Mar 2021 16:15:06 +0100
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> 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-00007-g79e228d0b611-dirty #99
> > 
> >     Call Trace:
> >      [<a000000100014d10>] show_stack+0x90/0xc0
> >      [<a000000101111d90>] dump_stack+0x150/0x1c0
> >      [<a0000001000cbec0>] ___might_sleep+0x1c0/0x2a0
> >      [<a0000001000cc040>] __might_sleep+0xa0/0x160
> >      [<a000000100399960>] __alloc_pages_nodemask+0x1a0/0x600
> >      [<a0000001003b71b0>] alloc_page_interleave+0x30/0x1c0
> >      [<a0000001003b9b60>] alloc_pages_current+0x2c0/0x340
> >      [<a00000010038c270>] __get_free_pages+0x30/0xa0
> >      [<a000000100044730>] ia64_mca_cpu_init+0x2d0/0x3a0
> >      [<a000000100023430>] cpu_init+0x8b0/0x1440
> >      [<a000000100054680>] start_secondary+0x60/0x700
> >      [<a00000010111e1d0>] 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 <akpm@linux-foundation.org>
> > CC: linux-ia64@vger.kernel.org
> > Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
> > ---
> >  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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
  2021-03-23 17:47   ` Sergei Trofimovich
@ 2021-03-24 10:20       ` John Paul Adrian Glaubitz
  0 siblings, 0 replies; 10+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-03-24 10:20 UTC (permalink / raw)
  To: Sergei Trofimovich; +Cc: Andrew Morton, linux-kernel, linux-ia64

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 <glaubitz@physik.fu-berlin.de> 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-00007-g79e228d0b611-dirty #99
>>>
>>>     Call Trace:
>>>      [<a000000100014d10>] show_stack+0x90/0xc0
>>>      [<a000000101111d90>] dump_stack+0x150/0x1c0
>>>      [<a0000001000cbec0>] ___might_sleep+0x1c0/0x2a0
>>>      [<a0000001000cc040>] __might_sleep+0xa0/0x160
>>>      [<a000000100399960>] __alloc_pages_nodemask+0x1a0/0x600
>>>      [<a0000001003b71b0>] alloc_page_interleave+0x30/0x1c0
>>>      [<a0000001003b9b60>] alloc_pages_current+0x2c0/0x340
>>>      [<a00000010038c270>] __get_free_pages+0x30/0xa0
>>>      [<a000000100044730>] ia64_mca_cpu_init+0x2d0/0x3a0
>>>      [<a000000100023430>] cpu_init+0x8b0/0x1440
>>>      [<a000000100054680>] start_secondary+0x60/0x700
>>>      [<a00000010111e1d0>] 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 <akpm@linux-foundation.org>
>>> CC: linux-ia64@vger.kernel.org
>>> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
>>> ---
>>>  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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
@ 2021-03-24 10:20       ` John Paul Adrian Glaubitz
  0 siblings, 0 replies; 10+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-03-24 10:20 UTC (permalink / raw)
  To: Sergei Trofimovich; +Cc: Andrew Morton, linux-kernel, linux-ia64

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 <glaubitz@physik.fu-berlin.de> 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-00007-g79e228d0b611-dirty #99
>>>
>>>     Call Trace:
>>>      [<a000000100014d10>] show_stack+0x90/0xc0
>>>      [<a000000101111d90>] dump_stack+0x150/0x1c0
>>>      [<a0000001000cbec0>] ___might_sleep+0x1c0/0x2a0
>>>      [<a0000001000cc040>] __might_sleep+0xa0/0x160
>>>      [<a000000100399960>] __alloc_pages_nodemask+0x1a0/0x600
>>>      [<a0000001003b71b0>] alloc_page_interleave+0x30/0x1c0
>>>      [<a0000001003b9b60>] alloc_pages_current+0x2c0/0x340
>>>      [<a00000010038c270>] __get_free_pages+0x30/0xa0
>>>      [<a000000100044730>] ia64_mca_cpu_init+0x2d0/0x3a0
>>>      [<a000000100023430>] cpu_init+0x8b0/0x1440
>>>      [<a000000100054680>] start_secondary+0x60/0x700
>>>      [<a00000010111e1d0>] 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 <akpm@linux-foundation.org>
>>> CC: linux-ia64@vger.kernel.org
>>> Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
>>> ---
>>>  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 - glaubitz@debian.org
`. `'   Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
  2021-03-24 10:20       ` John Paul Adrian Glaubitz
@ 2021-03-24 22:39         ` Andrew Morton
  -1 siblings, 0 replies; 10+ messages in thread
From: Andrew Morton @ 2021-03-24 22:39 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz; +Cc: Sergei Trofimovich, linux-kernel, linux-ia64

On Wed, 24 Mar 2021 11:20:45 +0100 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> 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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
@ 2021-03-24 22:39         ` Andrew Morton
  0 siblings, 0 replies; 10+ messages in thread
From: Andrew Morton @ 2021-03-24 22:39 UTC (permalink / raw)
  To: John Paul Adrian Glaubitz; +Cc: Sergei Trofimovich, linux-kernel, linux-ia64

On Wed, 24 Mar 2021 11:20:45 +0100 John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> 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

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
  2021-03-24 22:39         ` Andrew Morton
@ 2021-03-24 22:57           ` John Paul Adrian Glaubitz
  -1 siblings, 0 replies; 10+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-03-24 22:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Sergei Trofimovich, linux-kernel, linux-ia64

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 <glaubitz@physik.fu-berlin.de> 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&m=161652285123466&w=2
> https://marc.info/?l=linux-netdev&m=161652400124112&w=2

Thanks,
Adrian

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC
@ 2021-03-24 22:57           ` John Paul Adrian Glaubitz
  0 siblings, 0 replies; 10+ messages in thread
From: John Paul Adrian Glaubitz @ 2021-03-24 22:57 UTC (permalink / raw)
  To: Andrew Morton; +Cc: Sergei Trofimovich, linux-kernel, linux-ia64

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 <glaubitz@physik.fu-berlin.de> 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&m\x161652285123466&w=2
> https://marc.info/?l=linux-netdev&m\x161652400124112&w=2

Thanks,
Adrian

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

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2021-03-24 22:58 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-03-15  8:50 [PATCH] ia64: mca: allocate early mca with GFP_ATOMIC Sergei Trofimovich
2021-03-23 15:15 ` John Paul Adrian Glaubitz
2021-03-23 15:15   ` John Paul Adrian Glaubitz
2021-03-23 17:47   ` Sergei Trofimovich
2021-03-24 10:20     ` John Paul Adrian Glaubitz
2021-03-24 10:20       ` John Paul Adrian Glaubitz
2021-03-24 22:39       ` Andrew Morton
2021-03-24 22:39         ` Andrew Morton
2021-03-24 22:57         ` John Paul Adrian Glaubitz
2021-03-24 22:57           ` John Paul Adrian Glaubitz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.