Skip to contentSkip to conversation

Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly non-modular vs CONFIG_TIMER_STATS)

PATCH Christian Borntraeger 4 participants 10 messages Jan 28, 2016 – Jan 29, 2016

Subsystems (2)
Memory management HugeTLB
lore
Share & tools
lore

Christian Borntraeger

author
#0 lore raw

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
 
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)

makes the problem go away.
Not sure yet, what CONFIG_TIMER_STATS changes in terms of kobject, though.

[    0.998607] kobject: '(null)' (0000000000000010): is not initialized, yet kobject_get() is being called.
[    0.998620] ------------[ cut here ]------------
[    0.998621] WARNING: at lib/kobject.c:597
[    0.998622] Modules linked in:
[    0.998625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc1 #174
[    0.998626] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998628] Krnl PSW : 0704c00180000000 000000000058276c (kobject_get+0x6c/0x90)
[    0.998632]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000232720000 000000000000005c 0000000000000001
[    0.998635]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998636]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998637]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998643] Krnl Code: 000000000058275c: c02000267259	larl	%%r2,a50c0e
           0000000000582762: c0e5ffe82b17	brasl	%%r14,287d90
          #0000000000582768: a7f40001		brc	15,58276a
          >000000000058276c: a7f4ffe2		brc	15,582730
           0000000000582770: c010003d24f3	larl	%%r1,d27156
           0000000000582776: 95001000		cli	0(%%r1),0
           000000000058277a: a774ffe6		brc	7,582746
           000000000058277e: a7f40001		brc	15,582780
[    0.998653] Call Trace:
[    0.998655] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998657]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998658]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998660]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998662]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998663]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998665]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998666]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998668]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998670]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998671]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998673] no locks held by swapper/0/1.
[    0.998673] Last Breaking-Event-Address:
[    0.998675]  [<0000000000582768>] kobject_get+0x68/0x90
[    0.998678] ---[ end trace cae7490da7950580 ]---
[    0.998679] Unable to handle kernel pointer dereference in virtual kernel address space
[    0.998681] failing address: 0000000000000000 TEID: 0000000000000483
[    0.998681] Fault in home space mode while using kernel ASCE.
[    0.998684] AS:0000000000fb1007 R3:000000023ffcf007 S:000000023fff8000 P:000000000000003d 
[    0.998719] Oops: 0004 ilc:3 [#1] SMP DEBUG_PAGEALLOC
[    0.998721] Modules linked in:
[    0.998723] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.5.0-rc1 #174
[    0.998725] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998726] Krnl PSW : 0704c00180000000 0000000000582734 (kobject_get+0x34/0x90)
[    0.998729]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000200000001 000000000000005c 0000000000000001
[    0.998731]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998733]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998734]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998739] Krnl Code: 0000000000582728: 9180203c		tm	60(%%r2),128
           000000000058272c: a7840013		brc	8,582752
          #0000000000582730: a7180001		lhi	%%r1,1
          >0000000000582734: eb11d03800f8	laa	%%r1,%%r1,56(%%r13)
           000000000058273a: 07e0		bcr	14,%%r0
           000000000058273c: a71a0001		ahi	%%r1,1
           0000000000582740: ec1c0018017e	cij	%%r1,1,12,582770
           0000000000582746: b904002d		lgr	%%r2,%%r13
[    0.998839] Call Trace:
[    0.998841] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998843]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998844]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998846]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998847]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998849]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998850]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998852]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998853]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998855]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998856]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998857] INFO: lockdep is turned off.
[    0.998858] Last Breaking-Event-Address:
[    0.998859]  [<000000000058276c>] kobject_get+0x6c/0x90
[    0.998861]  
[    0.998863] Kernel panic - not syncing: Fatal exception: panic_on_oops
#1 lore raw
Quoted 20 lines

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
 
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)
Quoted 1 line

makes the problem go away.

Helps more if a patch is delivered.

thanks
Hillf

Quoted 80 lines

Not sure yet, what CONFIG_TIMER_STATS changes in terms of kobject, though.

[    0.998607] kobject: '(null)' (0000000000000010): is not initialized, yet kobject_get() is being called.
[    0.998620] ------------[ cut here ]------------
[    0.998621] WARNING: at lib/kobject.c:597
[    0.998622] Modules linked in:
[    0.998625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc1 #174
[    0.998626] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998628] Krnl PSW : 0704c00180000000 000000000058276c (kobject_get+0x6c/0x90)
[    0.998632]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000232720000 000000000000005c 0000000000000001
[    0.998635]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998636]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998637]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998643] Krnl Code: 000000000058275c: c02000267259	larl	%%r2,a50c0e
           0000000000582762: c0e5ffe82b17	brasl	%%r14,287d90
          #0000000000582768: a7f40001		brc	15,58276a
          >000000000058276c: a7f4ffe2		brc	15,582730
           0000000000582770: c010003d24f3	larl	%%r1,d27156
           0000000000582776: 95001000		cli	0(%%r1),0
           000000000058277a: a774ffe6		brc	7,582746
           000000000058277e: a7f40001		brc	15,582780
[    0.998653] Call Trace:
[    0.998655] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998657]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998658]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998660]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998662]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998663]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998665]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998666]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998668]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998670]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998671]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998673] no locks held by swapper/0/1.
[    0.998673] Last Breaking-Event-Address:
[    0.998675]  [<0000000000582768>] kobject_get+0x68/0x90
[    0.998678] ---[ end trace cae7490da7950580 ]---
[    0.998679] Unable to handle kernel pointer dereference in virtual kernel address space
[    0.998681] failing address: 0000000000000000 TEID: 0000000000000483
[    0.998681] Fault in home space mode while using kernel ASCE.
[    0.998684] AS:0000000000fb1007 R3:000000023ffcf007 S:000000023fff8000 P:000000000000003d
[    0.998719] Oops: 0004 ilc:3 [#1] SMP DEBUG_PAGEALLOC
[    0.998721] Modules linked in:
[    0.998723] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.5.0-rc1 #174
[    0.998725] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998726] Krnl PSW : 0704c00180000000 0000000000582734 (kobject_get+0x34/0x90)
[    0.998729]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000200000001 000000000000005c 0000000000000001
[    0.998731]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998733]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998734]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998739] Krnl Code: 0000000000582728: 9180203c		tm	60(%%r2),128
           000000000058272c: a7840013		brc	8,582752
          #0000000000582730: a7180001		lhi	%%r1,1
          >0000000000582734: eb11d03800f8	laa	%%r1,%%r1,56(%%r13)
           000000000058273a: 07e0		bcr	14,%%r0
           000000000058273c: a71a0001		ahi	%%r1,1
           0000000000582740: ec1c0018017e	cij	%%r1,1,12,582770
           0000000000582746: b904002d		lgr	%%r2,%%r13
[    0.998839] Call Trace:
[    0.998841] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998843]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998844]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998846]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998847]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998849]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998850]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998852]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998853]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998855]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998856]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998857] INFO: lockdep is turned off.
[    0.998858] Last Breaking-Event-Address:
[    0.998859]  [<000000000058276c>] kobject_get+0x6c/0x90
[    0.998861]
[    0.998863] Kernel panic - not syncing: Fatal exception: panic_on_oops
author
#2 lore raw
Quoted 17 lines · Hillf Danton
Quoted 17 lines

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
Quoted 6 lines
Quoted 4 lines
mm/hugetlb.c +0 -0
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)

makes the problem go away.

Helps more if a patch is delivered.

The problem is that the original change was intentional. So I do not not what the right fix is.

Quoted 85 lines

thanks
Hillf

Quoted 80 lines

Not sure yet, what CONFIG_TIMER_STATS changes in terms of kobject, though.

[    0.998607] kobject: '(null)' (0000000000000010): is not initialized, yet kobject_get() is being called.
[    0.998620] ------------[ cut here ]------------
[    0.998621] WARNING: at lib/kobject.c:597
[    0.998622] Modules linked in:
[    0.998625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc1 #174
[    0.998626] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998628] Krnl PSW : 0704c00180000000 000000000058276c (kobject_get+0x6c/0x90)
[    0.998632]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000232720000 000000000000005c 0000000000000001
[    0.998635]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998636]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998637]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998643] Krnl Code: 000000000058275c: c02000267259	larl	%%r2,a50c0e
           0000000000582762: c0e5ffe82b17	brasl	%%r14,287d90
          #0000000000582768: a7f40001		brc	15,58276a
          >000000000058276c: a7f4ffe2		brc	15,582730
           0000000000582770: c010003d24f3	larl	%%r1,d27156
           0000000000582776: 95001000		cli	0(%%r1),0
           000000000058277a: a774ffe6		brc	7,582746
           000000000058277e: a7f40001		brc	15,582780
[    0.998653] Call Trace:
[    0.998655] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998657]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998658]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998660]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998662]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998663]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998665]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998666]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998668]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998670]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998671]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998673] no locks held by swapper/0/1.
[    0.998673] Last Breaking-Event-Address:
[    0.998675]  [<0000000000582768>] kobject_get+0x68/0x90
[    0.998678] ---[ end trace cae7490da7950580 ]---
[    0.998679] Unable to handle kernel pointer dereference in virtual kernel address space
[    0.998681] failing address: 0000000000000000 TEID: 0000000000000483
[    0.998681] Fault in home space mode while using kernel ASCE.
[    0.998684] AS:0000000000fb1007 R3:000000023ffcf007 S:000000023fff8000 P:000000000000003d
[    0.998719] Oops: 0004 ilc:3 [#1] SMP DEBUG_PAGEALLOC
[    0.998721] Modules linked in:
[    0.998723] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.5.0-rc1 #174
[    0.998725] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998726] Krnl PSW : 0704c00180000000 0000000000582734 (kobject_get+0x34/0x90)
[    0.998729]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000200000001 000000000000005c 0000000000000001
[    0.998731]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998733]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998734]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998739] Krnl Code: 0000000000582728: 9180203c		tm	60(%%r2),128
           000000000058272c: a7840013		brc	8,582752
          #0000000000582730: a7180001		lhi	%%r1,1
          >0000000000582734: eb11d03800f8	laa	%%r1,%%r1,56(%%r13)
           000000000058273a: 07e0		bcr	14,%%r0
           000000000058273c: a71a0001		ahi	%%r1,1
           0000000000582740: ec1c0018017e	cij	%%r1,1,12,582770
           0000000000582746: b904002d		lgr	%%r2,%%r13
[    0.998839] Call Trace:
[    0.998841] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998843]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998844]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998846]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998847]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998849]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998850]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998852]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998853]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998855]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998856]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998857] INFO: lockdep is turned off.
[    0.998858] Last Breaking-Event-Address:
[    0.998859]  [<000000000058276c>] kobject_get+0x6c/0x90
[    0.998861]
[    0.998863] Kernel panic - not syncing: Fatal exception: panic_on_oops
#3 lore raw
Quoted 21 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 20 lines · Hillf Danton
Quoted 20 lines

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
 
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)
Quoted 6 lines
Quoted 3 lines
Quoted 1 line

makes the problem go away.

Helps more if a patch is delivered.

The problem is that the original change was intentional. So I do not not what the right fix is.

Thanks for the report ; let me see if I can work out what TIMER_STATS is doing to cause this sometime today.

P.
--

Quoted 88 lines
Quoted 87 lines

thanks
Hillf

Quoted 80 lines

Not sure yet, what CONFIG_TIMER_STATS changes in terms of kobject, though.

[    0.998607] kobject: '(null)' (0000000000000010): is not initialized, yet kobject_get() is being called.
[    0.998620] ------------[ cut here ]------------
[    0.998621] WARNING: at lib/kobject.c:597
[    0.998622] Modules linked in:
[    0.998625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc1 #174
[    0.998626] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998628] Krnl PSW : 0704c00180000000 000000000058276c (kobject_get+0x6c/0x90)
[    0.998632]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000232720000 000000000000005c 0000000000000001
[    0.998635]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998636]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998637]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998643] Krnl Code: 000000000058275c: c02000267259	larl	%%r2,a50c0e
           0000000000582762: c0e5ffe82b17	brasl	%%r14,287d90
          #0000000000582768: a7f40001		brc	15,58276a
          >000000000058276c: a7f4ffe2		brc	15,582730
           0000000000582770: c010003d24f3	larl	%%r1,d27156
           0000000000582776: 95001000		cli	0(%%r1),0
           000000000058277a: a774ffe6		brc	7,582746
           000000000058277e: a7f40001		brc	15,582780
[    0.998653] Call Trace:
[    0.998655] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998657]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998658]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998660]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998662]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998663]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998665]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998666]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998668]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998670]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998671]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998673] no locks held by swapper/0/1.
[    0.998673] Last Breaking-Event-Address:
[    0.998675]  [<0000000000582768>] kobject_get+0x68/0x90
[    0.998678] ---[ end trace cae7490da7950580 ]---
[    0.998679] Unable to handle kernel pointer dereference in virtual kernel address space
[    0.998681] failing address: 0000000000000000 TEID: 0000000000000483
[    0.998681] Fault in home space mode while using kernel ASCE.
[    0.998684] AS:0000000000fb1007 R3:000000023ffcf007 S:000000023fff8000 P:000000000000003d
[    0.998719] Oops: 0004 ilc:3 [#1] SMP DEBUG_PAGEALLOC
[    0.998721] Modules linked in:
[    0.998723] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.5.0-rc1 #174
[    0.998725] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998726] Krnl PSW : 0704c00180000000 0000000000582734 (kobject_get+0x34/0x90)
[    0.998729]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000200000001 000000000000005c 0000000000000001
[    0.998731]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998733]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998734]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998739] Krnl Code: 0000000000582728: 9180203c		tm	60(%%r2),128
           000000000058272c: a7840013		brc	8,582752
          #0000000000582730: a7180001		lhi	%%r1,1
          >0000000000582734: eb11d03800f8	laa	%%r1,%%r1,56(%%r13)
           000000000058273a: 07e0		bcr	14,%%r0
           000000000058273c: a71a0001		ahi	%%r1,1
           0000000000582740: ec1c0018017e	cij	%%r1,1,12,582770
           0000000000582746: b904002d		lgr	%%r2,%%r13
[    0.998839] Call Trace:
[    0.998841] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998843]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998844]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998846]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998847]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998849]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998850]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998852]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998853]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998855]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998856]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998857] INFO: lockdep is turned off.
[    0.998858] Last Breaking-Event-Address:
[    0.998859]  [<000000000058276c>] kobject_get+0x6c/0x90
[    0.998861]
[    0.998863] Kernel panic - not syncing: Fatal exception: panic_on_oops
#4 lore raw
Quoted 27 lines · Paul Gortmaker
Quoted 25 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 23 lines · Hillf Danton
Quoted 20 lines

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
 
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)
Quoted 1 line

makes the problem go away.

Helps more if a patch is delivered.

Quoted 6 lines
Quoted 2 lines

The problem is that the original change was intentional. So I do not not what the right fix is.

Thanks for the report ; let me see if I can work out what TIMER_STATS is doing to cause this sometime today.

Hmmm? CONFIG_TIMER_STATS is set in my config and I am not seeing the issue. Not sure, but it looks like Christian is building/running on s390. This 'might' be a contributing factor.

Signature · 1 line
Mike Kravetz
Quoted 91 lines

P.
--

Quoted 88 lines
Quoted 87 lines

thanks
Hillf

Quoted 80 lines

Not sure yet, what CONFIG_TIMER_STATS changes in terms of kobject, though.

[    0.998607] kobject: '(null)' (0000000000000010): is not initialized, yet kobject_get() is being called.
[    0.998620] ------------[ cut here ]------------
[    0.998621] WARNING: at lib/kobject.c:597
[    0.998622] Modules linked in:
[    0.998625] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.5.0-rc1 #174
[    0.998626] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998628] Krnl PSW : 0704c00180000000 000000000058276c (kobject_get+0x6c/0x90)
[    0.998632]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000232720000 000000000000005c 0000000000000001
[    0.998635]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998636]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998637]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998643] Krnl Code: 000000000058275c: c02000267259	larl	%%r2,a50c0e
           0000000000582762: c0e5ffe82b17	brasl	%%r14,287d90
          #0000000000582768: a7f40001		brc	15,58276a
          >000000000058276c: a7f4ffe2		brc	15,582730
           0000000000582770: c010003d24f3	larl	%%r1,d27156
           0000000000582776: 95001000		cli	0(%%r1),0
           000000000058277a: a774ffe6		brc	7,582746
           000000000058277e: a7f40001		brc	15,582780
[    0.998653] Call Trace:
[    0.998655] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998657]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998658]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998660]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998662]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998663]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998665]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998666]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998668]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998670]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998671]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998673] no locks held by swapper/0/1.
[    0.998673] Last Breaking-Event-Address:
[    0.998675]  [<0000000000582768>] kobject_get+0x68/0x90
[    0.998678] ---[ end trace cae7490da7950580 ]---
[    0.998679] Unable to handle kernel pointer dereference in virtual kernel address space
[    0.998681] failing address: 0000000000000000 TEID: 0000000000000483
[    0.998681] Fault in home space mode while using kernel ASCE.
[    0.998684] AS:0000000000fb1007 R3:000000023ffcf007 S:000000023fff8000 P:000000000000003d
[    0.998719] Oops: 0004 ilc:3 [#1] SMP DEBUG_PAGEALLOC
[    0.998721] Modules linked in:
[    0.998723] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W       4.5.0-rc1 #174
[    0.998725] task: 0000000232720000 ti: 000000023270c000 task.ti: 000000023270c000
[    0.998726] Krnl PSW : 0704c00180000000 0000000000582734 (kobject_get+0x34/0x90)
[    0.998729]            R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 EA:3
Krnl GPRS: 000000000000006c 0000000200000001 000000000000005c 0000000000000001
[    0.998731]            0000000000287e04 0000000000000000 0000000000dd99a8 0000000000000000
[    0.998733]            0000000000d86008 0000000000000000 0000000000000000 0000000000000000
[    0.998734]            0000000000000010 0000000000000010 0000000000582768 000000023270fbb0
[    0.998739] Krnl Code: 0000000000582728: 9180203c		tm	60(%%r2),128
           000000000058272c: a7840013		brc	8,582752
          #0000000000582730: a7180001		lhi	%%r1,1
          >0000000000582734: eb11d03800f8	laa	%%r1,%%r1,56(%%r13)
           000000000058273a: 07e0		bcr	14,%%r0
           000000000058273c: a71a0001		ahi	%%r1,1
           0000000000582740: ec1c0018017e	cij	%%r1,1,12,582770
           0000000000582746: b904002d		lgr	%%r2,%%r13
[    0.998839] Call Trace:
[    0.998841] ([<0000000000582768>] kobject_get+0x68/0x90)
[    0.998843]  [<000000000058318e>] kobject_add_internal+0x46/0x2e8
[    0.998844]  [<0000000000583684>] kobject_add+0x7c/0xd0
[    0.998846]  [<0000000000583722>] kobject_create_and_add+0x4a/0x98
[    0.998847]  [<00000000002e8ee0>] hugetlb_register_node+0x68/0x130
[    0.998849]  [<0000000000d59ef0>] hugetlb_init+0x4f0/0x600
[    0.998850]  [<00000000001001da>] do_one_initcall+0xa2/0x1b8
[    0.998852]  [<0000000000d3ae52>] kernel_init_freeable+0x232/0x2e0
[    0.998853]  [<00000000008312d2>] kernel_init+0x2a/0x120
[    0.998855]  [<000000000083d332>] kernel_thread_starter+0x6/0xc
[    0.998856]  [<000000000083d32c>] kernel_thread_starter+0x0/0xc
[    0.998857] INFO: lockdep is turned off.
[    0.998858] Last Breaking-Event-Address:
[    0.998859]  [<000000000058276c>] kobject_get+0x6c/0x90
[    0.998861]
[    0.998863] Kernel panic - not syncing: Fatal exception: panic_on_oops
#5 lore raw
Quoted 31 lines · Mike Kravetz
Quoted 30 lines · Paul Gortmaker
Quoted 27 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 17 lines · Hillf Danton
Quoted 17 lines

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
Quoted 6 lines
Quoted 4 lines
mm/hugetlb.c +0 -0
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)

makes the problem go away.

Helps more if a patch is delivered.

The problem is that the original change was intentional. So I do not not what the right fix is.

Quoted 7 lines
Quoted 3 lines

Thanks for the report ; let me see if I can work out what TIMER_STATS is doing to cause this sometime today.

Hmmm? CONFIG_TIMER_STATS is set in my config and I am not seeing the issue. Not sure, but it looks like Christian is building/running on s390. This 'might' be a contributing factor.

I do not see how CONFIG_TIMER_STATS contributes to this issue. However, on s390 numa nodes are initialized at device_initcall in the appropriately named routine numa_init_late(). hugetlb_init must be done after numa initialization. So, I suggest we just move the hugetlb initialization back to device_initcall. What do you think Paul? Patch below.

Is there a way to add checks for this type of thing in the code? I'm guessing not.

Signature · 17 lines
Mike Kravetz

hugetlb: move hugetlb_init and init_hugetlbfs_fs to device_initcall level

hugetlb_init() must be called after numa initialization for all
architectures.  Currently, numa initialization happens as late as
device_initcall.  Therefore, move hugetlb_init to device_initcall
level.  init_hugetlbfs_fs() depends on hugetlb_init(), so move it
to device_initcall as well.

Fixes: 3e89e1c5ea ("hugetlb: make mm and fs code explicitly non-modular")
Reported-by: Christian Borntraeger <[email protected]>
Signed-off-by: Mike Kravetz <[email protected]>
---
 fs/hugetlbfs/inode.c | 3 ++-
 mm/hugetlb.c         | 6 +++++-
 2 files changed, 7 insertions(+), 2 deletions(-)
fs/hugetlbfs/inode.c +2 -1
index 540ddc9..d27d3f6 100644
@@ -1363,4 +1363,5 @@ static int __init init_hugetlbfs_fs(void)
  out2:
 	return error;
 }
-fs_initcall(init_hugetlbfs_fs)
+/* Must happen after hugetlb_init() */
+device_initcall(init_hugetlbfs_fs)
mm/hugetlb.c +2 -1
index 12908dc..a4c0015 100644
@@ -2653,7 +2653,11 @@ static int __init hugetlb_init(void)
 		mutex_init(&hugetlb_fault_mutex_table[i]);
 	return 0;
 }
-subsys_initcall(hugetlb_init);
+/*
+ * hugetlb_init must be called after numa initialization for all

architectures.
+ * Currently, this is as late as device_initcall().
+ */
+device_initcall(hugetlb_init);

/* Should be called on processing a hugepagesz=... option */ void __init hugetlb_add_hstate(unsigned int order)

Signature · 1 line
2.4.3
#6 lore raw
Quoted 36 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 35 lines · Mike Kravetz
Quoted 33 lines · Paul Gortmaker
Quoted 21 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 20 lines · Hillf Danton
Quoted 20 lines

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
 
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)
Quoted 6 lines
Quoted 3 lines
Quoted 1 line

makes the problem go away.

Helps more if a patch is delivered.

The problem is that the original change was intentional. So I do not not what the right fix is.

Thanks for the report ; let me see if I can work out what TIMER_STATS is doing to cause this sometime today.

Quoted 5 lines
Quoted 3 lines

Hmmm? CONFIG_TIMER_STATS is set in my config and I am not seeing the issue. Not sure, but it looks like Christian is building/running on s390. This 'might' be a contributing factor.

I do not see how CONFIG_TIMER_STATS contributes to this issue. However,

I looked at all the TIMER_STATS ifdef blocks and was also thinking the same thing. If it did toggle the problem then it was a red herring. My test config had this set and I retested x86-64 today with it set.

Quoted 4 lines

on s390 numa nodes are initialized at device_initcall in the appropriately named routine numa_init_late(). hugetlb_init must be done after numa initialization. So, I suggest we just move the hugetlb initialization back to device_initcall. What do you think Paul? Patch below.

We could, but that ignores the fact that the original priorities worked by chance and not by design, as my commit log indicates. Instead, I'd like to know why S390 does core NUMA operations as late as
device_initcall. Setting up NUMA nodes should be arch_initcall or
subsys_initcall, or earlier --- it should not be device_initcall as if it was some leaf node UART driver or ethernet driver. There is no endpoint "device" in NUMA in this context.

If possible, I'd rather us look at the s390 ordering vs. doing a partial revert of what is IMHO a sensible change.

Can I do qemu s390 defconfig boots to see this locally, or is that simply unobtanium? I'd like to resolve this since I caused it, but I'd also like to avoid making a knee-jerk revert to do so.

Thanks,
P.
--

Quoted 55 lines

Is there a way to add checks for this type of thing in the code? I'm guessing not.

Signature · 17 lines
Mike Kravetz

hugetlb: move hugetlb_init and init_hugetlbfs_fs to device_initcall level

hugetlb_init() must be called after numa initialization for all
architectures.  Currently, numa initialization happens as late as
device_initcall.  Therefore, move hugetlb_init to device_initcall
level.  init_hugetlbfs_fs() depends on hugetlb_init(), so move it
to device_initcall as well.

Fixes: 3e89e1c5ea ("hugetlb: make mm and fs code explicitly non-modular")
Reported-by: Christian Borntraeger <[email protected]>
Signed-off-by: Mike Kravetz <[email protected]>
---
 fs/hugetlbfs/inode.c | 3 ++-
 mm/hugetlb.c         | 6 +++++-
 2 files changed, 7 insertions(+), 2 deletions(-)
fs/hugetlbfs/inode.c +2 -1
index 540ddc9..d27d3f6 100644
@@ -1363,4 +1363,5 @@ static int __init init_hugetlbfs_fs(void)
  out2:
 	return error;
 }
-fs_initcall(init_hugetlbfs_fs)
+/* Must happen after hugetlb_init() */
+device_initcall(init_hugetlbfs_fs)
mm/hugetlb.c +2 -1
index 12908dc..a4c0015 100644
@@ -2653,7 +2653,11 @@ static int __init hugetlb_init(void)
 		mutex_init(&hugetlb_fault_mutex_table[i]);
 	return 0;
 }
-subsys_initcall(hugetlb_init);
+/*
+ * hugetlb_init must be called after numa initialization for all

architectures.
+ * Currently, this is as late as device_initcall().
+ */
+device_initcall(hugetlb_init);

/* Should be called on processing a hugepagesz=... option */ void __init hugetlb_add_hstate(unsigned int order)

Signature · 1 line
2.4.3
Reviewed-by Heiko Carstens
#7 lore raw
Quoted 53 lines · Paul Gortmaker
Quoted 36 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 35 lines · Mike Kravetz
Quoted 33 lines · Paul Gortmaker
Quoted 21 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 20 lines · Hillf Danton
Quoted 20 lines

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
 
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)
Quoted 6 lines
Quoted 3 lines
Quoted 1 line

makes the problem go away.

Helps more if a patch is delivered.

The problem is that the original change was intentional. So I do not not what the right fix is.

Thanks for the report ; let me see if I can work out what TIMER_STATS is doing to cause this sometime today.

Quoted 5 lines
Quoted 3 lines

Hmmm? CONFIG_TIMER_STATS is set in my config and I am not seeing the issue. Not sure, but it looks like Christian is building/running on s390. This 'might' be a contributing factor.

I do not see how CONFIG_TIMER_STATS contributes to this issue. However,

I looked at all the TIMER_STATS ifdef blocks and was also thinking the same thing. If it did toggle the problem then it was a red herring. My test config had this set and I retested x86-64 today with it set.

Quoted 4 lines

on s390 numa nodes are initialized at device_initcall in the appropriately named routine numa_init_late(). hugetlb_init must be done after numa initialization. So, I suggest we just move the hugetlb initialization back to device_initcall. What do you think Paul? Patch below.

Quoted 7 lines

We could, but that ignores the fact that the original priorities worked by chance and not by design, as my commit log indicates. Instead, I'd like to know why S390 does core NUMA operations as late as
device_initcall. Setting up NUMA nodes should be arch_initcall or
subsys_initcall, or earlier --- it should not be device_initcall as if it was some leaf node UART driver or ethernet driver. There is no endpoint "device" in NUMA in this context.

This is in linux-next after 4.5-rc1

commit 2d0f76a6ca1f2cdcffca7ce130f67ec61caa0999

Author: Michael Holzheu <[email protected]>
Date:   Wed Jan 20 19:22:16 2016 +0100

s390/numa: move numa_init_late() from device to arch_initcall

Commit 3e89e1c5ea ("hugetlb: make mm and fs code explicitly
non-modular")
moves hugetlb_init() from module_init to subsys_initcall.

The hugetlb_init()->hugetlb_register_node() code accesses
"node->dev.kobj"
which is initialized in numa_init_late().

Since numa_init_late() is a device_initcall which is called *after* subsys_initcall the above mentioned patch breaks NUMA on s390.

So fix this and move numa_init_late() to arch_initcall.

Fixes 3e89e1c5ea ("hugetlb: make mm and fs code explicitly

non-modular")

Reviewed-by Heiko Carstens <[email protected]>
Signed-off-by Michael Holzheu <[email protected]>
Signed-off-by Martin Schwidefsky <[email protected]>
Signature · 1 line
Mike Kravetz
author
#8 lore raw
Quoted 81 lines · Mike Kravetz
Quoted 53 lines · Paul Gortmaker
Quoted 36 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 35 lines · Mike Kravetz
Quoted 33 lines · Paul Gortmaker
Quoted 21 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 20 lines · Hillf Danton
Quoted 20 lines

Paul,

the commit 3e89e1c5ea842 ("hugetlb: make mm and fs code explicitly non-modular") triggers belows warning/oops, if CONFIG_TIMER_STATS is set.

Looking at the patch the only "real" change is the init_call, and indeed

mm/hugetlb.c +1 -1
@@ -2653,7 +2653,7 @@ static int __init hugetlb_init(void)
                mutex_init(&hugetlb_fault_mutex_table[i]);
        return 0;
 }
-subsys_initcall(hugetlb_init);
+device_initcall(hugetlb_init);
 
 /* Should be called on processing a hugepagesz=... option */
 void __init hugetlb_add_hstate(unsigned int order)
Quoted 6 lines
Quoted 3 lines
Quoted 1 line

makes the problem go away.

Helps more if a patch is delivered.

The problem is that the original change was intentional. So I do not not what the right fix is.

Thanks for the report ; let me see if I can work out what TIMER_STATS is doing to cause this sometime today.

Quoted 5 lines
Quoted 3 lines

Hmmm? CONFIG_TIMER_STATS is set in my config and I am not seeing the issue. Not sure, but it looks like Christian is building/running on s390. This 'might' be a contributing factor.

I do not see how CONFIG_TIMER_STATS contributes to this issue. However,

I looked at all the TIMER_STATS ifdef blocks and was also thinking the same thing. If it did toggle the problem then it was a red herring. My test config had this set and I retested x86-64 today with it set.

Quoted 4 lines

on s390 numa nodes are initialized at device_initcall in the appropriately named routine numa_init_late(). hugetlb_init must be done after numa initialization. So, I suggest we just move the hugetlb initialization back to device_initcall. What do you think Paul? Patch below.

Quoted 7 lines

We could, but that ignores the fact that the original priorities worked by chance and not by design, as my commit log indicates. Instead, I'd like to know why S390 does core NUMA operations as late as
device_initcall. Setting up NUMA nodes should be arch_initcall or
subsys_initcall, or earlier --- it should not be device_initcall as if it was some leaf node UART driver or ethernet driver. There is no endpoint "device" in NUMA in this context.

This is in linux-next after 4.5-rc1

commit 2d0f76a6ca1f2cdcffca7ce130f67ec61caa0999

Author: Michael Holzheu <[email protected]>
Date:   Wed Jan 20 19:22:16 2016 +0100

s390/numa: move numa_init_late() from device to arch_initcall

Commit 3e89e1c5ea ("hugetlb: make mm and fs code explicitly
non-modular")
moves hugetlb_init() from module_init to subsys_initcall.

The hugetlb_init()->hugetlb_register_node() code accesses
"node->dev.kobj"
which is initialized in numa_init_late().

Since numa_init_late() is a device_initcall which is called *after* subsys_initcall the above mentioned patch breaks NUMA on s390.

Quoted 8 lines

So fix this and move numa_init_late() to arch_initcall.

Fixes 3e89e1c5ea ("hugetlb: make mm and fs code explicitly

non-modular")

Reviewed-by Heiko Carstens <[email protected]>
Signed-off-by Michael Holzheu <[email protected]>
Signed-off-by Martin Schwidefsky <[email protected]>

Ah, ok. thanks. Yes that makes a lot of sense. Thanks for pointing me to this patch.

#9 lore raw
In reply to Mike Kravetz
Quoted 4 lines · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…
Quoted 3 lines · Paul Gortmaker
Quoted 1 line · [Re: Regression: 4.5-rc1 (bisect: hugetlb: make mm and fs code explicitly…

On 01/28/2016 07:05 AM, Mike Kravetz wrote:

[...]

Quoted 13 lines
Quoted 5 lines
Quoted 4 lines

on s390 numa nodes are initialized at device_initcall in the appropriately named routine numa_init_late(). hugetlb_init must be done after numa initialization. So, I suggest we just move the hugetlb initialization back to device_initcall. What do you think Paul? Patch below.

Quoted 7 lines

We could, but that ignores the fact that the original priorities worked by chance and not by design, as my commit log indicates. Instead, I'd like to know why S390 does core NUMA operations as late as
device_initcall. Setting up NUMA nodes should be arch_initcall or
subsys_initcall, or earlier --- it should not be device_initcall as if it was some leaf node UART driver or ethernet driver. There is no endpoint "device" in NUMA in this context.

Quoted 7 lines

This is in linux-next after 4.5-rc1

commit 2d0f76a6ca1f2cdcffca7ce130f67ec61caa0999

Author: Michael Holzheu <[email protected]>
Date:   Wed Jan 20 19:22:16 2016 +0100

s390/numa: move numa_init_late() from device to arch_initcall

Nice. Too bad one of us didn't see this a few hours earlier, but oh well. At least it backs up what I said above.

Thanks,
Paul.
--

Quoted 22 lines

Commit 3e89e1c5ea ("hugetlb: make mm and fs code explicitly
non-modular")
moves hugetlb_init() from module_init to subsys_initcall.

The hugetlb_init()->hugetlb_register_node() code accesses
"node->dev.kobj"
which is initialized in numa_init_late().

Since numa_init_late() is a device_initcall which is called *after* subsys_initcall the above mentioned patch breaks NUMA on s390.

So fix this and move numa_init_late() to arch_initcall.

Fixes 3e89e1c5ea ("hugetlb: make mm and fs code explicitly

non-modular")

Reviewed-by Heiko Carstens <[email protected]>
Signed-off-by Michael Holzheu <[email protected]>
Signed-off-by Martin Schwidefsky <[email protected]>
Signature · 1 line
Mike Kravetz