Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1591408 > unrolled thread

Re: [lkp-robot] [x86] ed3ce2a917: BUG:unable_to_handle_kernel

Started byBorislav Petkov <bp@alien8.de>
First post2017-03-02 20:20 +0100
Last post2017-03-10 09:40 +0100
Articles 7 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [lkp-robot] [x86]  ed3ce2a917: BUG:unable_to_handle_kernel Borislav Petkov <bp@alien8.de> - 2017-03-02 20:20 +0100
    Re: [lkp-robot] [x86]  ed3ce2a917: BUG:unable_to_handle_kernel Ye Xiaolong <xiaolong.ye@intel.com> - 2017-03-09 03:30 +0100
      Re: [lkp-robot] [x86]  ed3ce2a917: BUG:unable_to_handle_kernel Fengguang Wu <fengguang.wu@intel.com> - 2017-03-09 03:40 +0100
        Re: [lkp-robot] [x86]  ed3ce2a917: BUG:unable_to_handle_kernel Borislav Petkov <bp@alien8.de> - 2017-03-09 09:20 +0100
      Re: [lkp-robot] [x86]  ed3ce2a917: BUG:unable_to_handle_kernel Borislav Petkov <bp@alien8.de> - 2017-03-09 09:20 +0100
        Re: [lkp-robot] [x86]  ed3ce2a917: BUG:unable_to_handle_kernel Ye Xiaolong <xiaolong.ye@intel.com> - 2017-03-10 03:40 +0100
          Re: [lkp-robot] [x86]  ed3ce2a917: BUG:unable_to_handle_kernel Borislav Petkov <bp@alien8.de> - 2017-03-10 09:40 +0100

#1591408 — Re: [lkp-robot] [x86] ed3ce2a917: BUG:unable_to_handle_kernel

FromBorislav Petkov <bp@alien8.de>
Date2017-03-02 20:20 +0100
SubjectRe: [lkp-robot] [x86] ed3ce2a917: BUG:unable_to_handle_kernel
Message-ID<tgEqC-6Lz-7@gated-at.bofh.it>
Hi,

On Thu, Mar 02, 2017 at 09:09:34AM +0800, kernel test robot wrote:
> 
> FYI, we noticed the following commit:
> 
> commit: ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f ("x86: Optimize clear_page()")
> url: https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170215-193441
> 
> 
> in testcase: will-it-scale
> with following parameters:
> 
> 	test: poll2
> 	cpufreq_governor: performance
> 
> test-description: Will It Scale takes a testcase and runs it from 1 through to n parallel copies to see if the testcase will scale. It builds both a process and threads based test in order to see any differences between the two.
> test-url: https://github.com/antonblanchard/will-it-scale

thanks for the report, I was able to reproduce.

BUT(!) this report is misleading because it talks about will-it-scale
but your splat happens when you kexec the kernel:

  [  336.340747] LKP: kexec loading...
  [  336.340852] 
  [  336.343323] kexec --noefi -l /tmp/cache/pkg/linux/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/vmlinuz-4.9.0-rc6-00134-ged3ce2a --initrd=/tmp/cache/initrd-concatenated
  [  336.343758] 
  [  337.893471] --append=ip=::::lkp-ivb-d01::dhcp root=/dev/ram0 user=lkp job=/lkp/scheduled/lkp-ivb-d01/will-it-scale-poll2-performance-debian-x86_64-2016-08-31.cgz-ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f-20170301-28072-1dqjyhl-11.yaml ARCH=x86_64 kconfig=x86_64-rhel-7.2 branch=linux-devel/devel-hourly-2017022612 commit=ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/vmlinuz-4.9.0-rc6-00134-ged3ce2a max_uptime=1500 RESULT_ROOT=/result/will-it-scale/poll2-performance/lkp-ivb-d01/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/11 LKP_SERVER=inn debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_
  [  337.895521] 
  [  339.467661] BUG: unable to handle kernel paging request at ffff8803cf2e2008
  [  339.468000] IP: [<ffffffff81061e71>] native_set_pmd+0x1/0x10
  ...


Maybe Fengguang has an idea what to do here, maybe something like add
markers to the log to denote where the test environment is prepared and
when the actual test starts. Then grep for those and generate the report
based on that...

Anyway, the diff is below, please try that ontop of tip's x86/asm branch
which already has the clear_page patch:

http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/asm

Thanks!

---
 arch/x86/include/asm/alternative.h | 17 -----------------
 arch/x86/include/asm/page_64.h     | 11 ++++++-----
 2 files changed, 6 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
index 12e3d8d607a9..1b020381ab38 100644
--- a/arch/x86/include/asm/alternative.h
+++ b/arch/x86/include/asm/alternative.h
@@ -227,23 +227,6 @@ static inline int alternatives_text_reserved(void *start, void *end)
 }
 
 /*
- * Like alternative_call(), but there are two features and respective functions.
- * If CPU has feature2, function2 is used.
- * Otherwise, if CPU has feature1, function1 is used.
- * Otherwise, old function is used.
- */
-#define alternative_void_call_2(oldfunc, newfunc1, feature1, newfunc2,		\
-				feature2, input...)				\
-{										\
-	register void *__sp asm(_ASM_SP);					\
-	asm volatile (ALTERNATIVE_2("call %P[old]", "call %P[new1]", feature1,	\
-		"call %P[new2]", feature2)					\
-		: "+r" (__sp)							\
-		: [old] "i" (oldfunc), [new1] "i" (newfunc1),			\
-		  [new2] "i" (newfunc2), ## input);				\
-}
-
-/*
  * use this macro(s) if you need more than one output parameter
  * in alternative_io
  */
diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h
index 254abce980a4..b4a0d43248cf 100644
--- a/arch/x86/include/asm/page_64.h
+++ b/arch/x86/include/asm/page_64.h
@@ -41,11 +41,12 @@ void clear_page_erms(void *page);
 
 static inline void clear_page(void *page)
 {
-	alternative_void_call_2(clear_page_orig,
-				clear_page_rep, X86_FEATURE_REP_GOOD,
-				clear_page_erms, X86_FEATURE_ERMS,
-				"D" (page)
-				: "memory", "rax", "rcx");
+	alternative_call_2(clear_page_orig,
+			   clear_page_rep, X86_FEATURE_REP_GOOD,
+			   clear_page_erms, X86_FEATURE_ERMS,
+			   "=D" (page),
+			   "0" (page)
+			   : "memory", "rax", "rcx");
 }
 
 void copy_page(void *to, void *from);
-- 
2.11.0


-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [next] | [standalone]

#1595636

FromYe Xiaolong <xiaolong.ye@intel.com>
Date2017-03-09 03:30 +0100
Message-ID<tiW01-6VB-1@gated-at.bofh.it>
In reply to#1591408
On 03/02, Borislav Petkov wrote:
>Hi,
>
>On Thu, Mar 02, 2017 at 09:09:34AM +0800, kernel test robot wrote:
>> 
>> FYI, we noticed the following commit:
>> 
>> commit: ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f ("x86: Optimize clear_page()")
>> url: https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170215-193441
>> 
>> 
>> in testcase: will-it-scale
>> with following parameters:
>> 
>> 	test: poll2
>> 	cpufreq_governor: performance
>> 
>> test-description: Will It Scale takes a testcase and runs it from 1 through to n parallel copies to see if the testcase will scale. It builds both a process and threads based test in order to see any differences between the two.
>> test-url: https://github.com/antonblanchard/will-it-scale
>
>thanks for the report, I was able to reproduce.
>
>BUT(!) this report is misleading because it talks about will-it-scale
>but your splat happens when you kexec the kernel:
>
>  [  336.340747] LKP: kexec loading...
>  [  336.340852] 
>  [  336.343323] kexec --noefi -l /tmp/cache/pkg/linux/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/vmlinuz-4.9.0-rc6-00134-ged3ce2a --initrd=/tmp/cache/initrd-concatenated
>  [  336.343758] 
>  [  337.893471] --append=ip=::::lkp-ivb-d01::dhcp root=/dev/ram0 user=lkp job=/lkp/scheduled/lkp-ivb-d01/will-it-scale-poll2-performance-debian-x86_64-2016-08-31.cgz-ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f-20170301-28072-1dqjyhl-11.yaml ARCH=x86_64 kconfig=x86_64-rhel-7.2 branch=linux-devel/devel-hourly-2017022612 commit=ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/vmlinuz-4.9.0-rc6-00134-ged3ce2a max_uptime=1500 RESULT_ROOT=/result/will-it-scale/poll2-performance/lkp-ivb-d01/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/11 LKP_SERVER=inn debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_
>  [  337.895521] 
>  [  339.467661] BUG: unable to handle kernel paging request at ffff8803cf2e2008
>  [  339.468000] IP: [<ffffffff81061e71>] native_set_pmd+0x1/0x10
>  ...
>
>
>Maybe Fengguang has an idea what to do here, maybe something like add
>markers to the log to denote where the test environment is prepared and
>when the actual test starts. Then grep for those and generate the report
>based on that...

Thanks for the suggestions, we'll keep improving the reports to avoid confusion
or misleading.

>
>Anyway, the diff is below, please try that ontop of tip's x86/asm branch
>which already has the clear_page patch:
>
>http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/asm
>
>Thanks!

Hmm, I've checkout the tip's x86/asm branch (HEAD is f25d38475 "x86/asm:
Optimize clear_page()"), but I failed to apply your diff on top of it (error
log as below). Could you provide a tree/branch which contains your fix, it would
much easier for 0day to catch and test.

error: patch failed: arch/x86/include/asm/alternative.h:227
error: arch/x86/include/asm/alternative.h: patch does not apply
error: patch failed: arch/x86/include/asm/page_64.h:41
error: arch/x86/include/asm/page_64.h: patch does not apply


Thanks,
Xiaolong
>
>---
> arch/x86/include/asm/alternative.h | 17 -----------------
> arch/x86/include/asm/page_64.h     | 11 ++++++-----
> 2 files changed, 6 insertions(+), 22 deletions(-)
>
>diff --git a/arch/x86/include/asm/alternative.h b/arch/x86/include/asm/alternative.h
>index 12e3d8d607a9..1b020381ab38 100644
>--- a/arch/x86/include/asm/alternative.h
>+++ b/arch/x86/include/asm/alternative.h
>@@ -227,23 +227,6 @@ static inline int alternatives_text_reserved(void *start, void *end)
> }
> 
> /*
>- * Like alternative_call(), but there are two features and respective functions.
>- * If CPU has feature2, function2 is used.
>- * Otherwise, if CPU has feature1, function1 is used.
>- * Otherwise, old function is used.
>- */
>-#define alternative_void_call_2(oldfunc, newfunc1, feature1, newfunc2,		\
>-				feature2, input...)				\
>-{										\
>-	register void *__sp asm(_ASM_SP);					\
>-	asm volatile (ALTERNATIVE_2("call %P[old]", "call %P[new1]", feature1,	\
>-		"call %P[new2]", feature2)					\
>-		: "+r" (__sp)							\
>-		: [old] "i" (oldfunc), [new1] "i" (newfunc1),			\
>-		  [new2] "i" (newfunc2), ## input);				\
>-}
>-
>-/*
>  * use this macro(s) if you need more than one output parameter
>  * in alternative_io
>  */
>diff --git a/arch/x86/include/asm/page_64.h b/arch/x86/include/asm/page_64.h
>index 254abce980a4..b4a0d43248cf 100644
>--- a/arch/x86/include/asm/page_64.h
>+++ b/arch/x86/include/asm/page_64.h
>@@ -41,11 +41,12 @@ void clear_page_erms(void *page);
> 
> static inline void clear_page(void *page)
> {
>-	alternative_void_call_2(clear_page_orig,
>-				clear_page_rep, X86_FEATURE_REP_GOOD,
>-				clear_page_erms, X86_FEATURE_ERMS,
>-				"D" (page)
>-				: "memory", "rax", "rcx");
>+	alternative_call_2(clear_page_orig,
>+			   clear_page_rep, X86_FEATURE_REP_GOOD,
>+			   clear_page_erms, X86_FEATURE_ERMS,
>+			   "=D" (page),
>+			   "0" (page)
>+			   : "memory", "rax", "rcx");
> }
> 
> void copy_page(void *to, void *from);
>-- 
>2.11.0
>
>
>-- 
>Regards/Gruss,
>    Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]

#1595641

FromFengguang Wu <fengguang.wu@intel.com>
Date2017-03-09 03:40 +0100
Message-ID<tiW9H-6YT-3@gated-at.bofh.it>
In reply to#1595636
On Thu, Mar 09, 2017 at 10:13:10AM +0800, Ye Xiaolong wrote:
>On 03/02, Borislav Petkov wrote:
>>Hi,
>>
>>On Thu, Mar 02, 2017 at 09:09:34AM +0800, kernel test robot wrote:
>>>
>>> FYI, we noticed the following commit:
>>>
>>> commit: ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f ("x86: Optimize clear_page()")
>>> url: https://github.com/0day-ci/linux/commits/Borislav-Petkov/x86-Optimize-clear_page/20170215-193441
>>>
>>>
>>> in testcase: will-it-scale
>>> with following parameters:
>>>
>>> 	test: poll2
>>> 	cpufreq_governor: performance
>>>
>>> test-description: Will It Scale takes a testcase and runs it from 1 through to n parallel copies to see if the testcase will scale. It builds both a process and threads based test in order to see any differences between the two.
>>> test-url: https://github.com/antonblanchard/will-it-scale
>>
>>thanks for the report, I was able to reproduce.
>>
>>BUT(!) this report is misleading because it talks about will-it-scale
>>but your splat happens when you kexec the kernel:
>>
>>  [  336.340747] LKP: kexec loading...
>>  [  336.340852]
>>  [  336.343323] kexec --noefi -l /tmp/cache/pkg/linux/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/vmlinuz-4.9.0-rc6-00134-ged3ce2a --initrd=/tmp/cache/initrd-concatenated
>>  [  336.343758]
>>  [  337.893471] --append=ip=::::lkp-ivb-d01::dhcp root=/dev/ram0 user=lkp job=/lkp/scheduled/lkp-ivb-d01/will-it-scale-poll2-performance-debian-x86_64-2016-08-31.cgz-ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f-20170301-28072-1dqjyhl-11.yaml ARCH=x86_64 kconfig=x86_64-rhel-7.2 branch=linux-devel/devel-hourly-2017022612 commit=ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f BOOT_IMAGE=/pkg/linux/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/vmlinuz-4.9.0-rc6-00134-ged3ce2a max_uptime=1500 RESULT_ROOT=/result/will-it-scale/poll2-performance/lkp-ivb-d01/debian-x86_64-2016-08-31.cgz/x86_64-rhel-7.2/gcc-6/ed3ce2a9172457ef7dbaa9f964e63dfde2bdcb5f/11 LKP_SERVER=inn debug apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8 systemd.log_level=err ignore_
>>  [  337.895521]
>>  [  339.467661] BUG: unable to handle kernel paging request at ffff8803cf2e2008
>>  [  339.468000] IP: [<ffffffff81061e71>] native_set_pmd+0x1/0x10
>>  ...
>>
>>
>>Maybe Fengguang has an idea what to do here, maybe something like add
>>markers to the log to denote where the test environment is prepared and
>>when the actual test starts. Then grep for those and generate the report
>>based on that...
>
>Thanks for the suggestions, we'll keep improving the reports to avoid confusion
>or misleading.

One possible improvement is to provide "lkp qemu" reproduce steps for
kernel oops -- it would be way more convenient and safe to follow than
"lkp run", since the later risks hang the physical machine.

As for the test description, the dmesg carries markers for the user
space test start/stop points, so the robot can easily tell whether the
oops happen during the test or before/after the test -- the latter may
well (but not always) indicate the oops is not relevant to the testcase,
but to the regular kernel boot/reboot/kexec process.

Thanks,
Fengguang

[toc] | [prev] | [next] | [standalone]

#1595785

FromBorislav Petkov <bp@alien8.de>
Date2017-03-09 09:20 +0100
Message-ID<tj1sK-2tF-19@gated-at.bofh.it>
In reply to#1595641
On Thu, Mar 09, 2017 at 10:30:52AM +0800, Fengguang Wu wrote:
> One possible improvement is to provide "lkp qemu" reproduce steps for
> kernel oops -- it would be way more convenient and safe to follow than
> "lkp run", since the later risks hang the physical machine.

Right, that would mean that the bug should be triggerable in qemu. Some
bugs happen on baremetal only though.

> As for the test description, the dmesg carries markers for the user
> space test start/stop points, so the robot can easily tell whether the
> oops happen during the test or before/after the test -- the latter may
> well (but not always) indicate the oops is not relevant to the testcase,
> but to the regular kernel boot/reboot/kexec process.

Right, if that is made part of the report, it would make the reports
better. Something like: "this happens when preparing our test env" or
"this happens while running this test blabla".

Thanks guys and keep up the good work!

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]

#1595787

FromBorislav Petkov <bp@alien8.de>
Date2017-03-09 09:20 +0100
Message-ID<tj1sK-2tF-21@gated-at.bofh.it>
In reply to#1595636
On Thu, Mar 09, 2017 at 10:13:10AM +0800, Ye Xiaolong wrote:
> >Anyway, the diff is below, please try that ontop of tip's x86/asm branch
> >which already has the clear_page patch:
> >
> >http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/asm
> >
> >Thanks!
> 
> Hmm, I've checkout the tip's x86/asm branch (HEAD is f25d38475 "x86/asm:
> Optimize clear_page()"), but I failed to apply your diff on top of it (error
> log as below).

Right, Ingo merged the diff I gave you already into the patch there
so that x86/asm already contains the fixed version. You could run the
current tip/x86/asm branch to confirm that it fixes the issue for you.

Thanks.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]

#1596572

FromYe Xiaolong <xiaolong.ye@intel.com>
Date2017-03-10 03:40 +0100
Message-ID<tjiDf-5vT-7@gated-at.bofh.it>
In reply to#1595787
On 03/09, Borislav Petkov wrote:
>On Thu, Mar 09, 2017 at 10:13:10AM +0800, Ye Xiaolong wrote:
>> >Anyway, the diff is below, please try that ontop of tip's x86/asm branch
>> >which already has the clear_page patch:
>> >
>> >http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/log/?h=x86/asm
>> >
>> >Thanks!
>> 
>> Hmm, I've checkout the tip's x86/asm branch (HEAD is f25d38475 "x86/asm:
>> Optimize clear_page()"), but I failed to apply your diff on top of it (error
>> log as below).
>
>Right, Ingo merged the diff I gave you already into the patch there
>so that x86/asm already contains the fixed version. You could run the
>current tip/x86/asm branch to confirm that it fixes the issue for you.

Previous kernel bug is gone for 10 times test of HEAD of tip/x86/asm. (f25d3847
"x86/asm: Optimize clear_page()")

Tested-by: Xiaolong Ye <xiaolong.ye@intel.com>

Thanks,
Xiaolong
>
>Thanks.
>
>-- 
>Regards/Gruss,
>    Boris.
>
>Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [next] | [standalone]

#1596709

FromBorislav Petkov <bp@alien8.de>
Date2017-03-10 09:40 +0100
Message-ID<tjofE-1eN-11@gated-at.bofh.it>
In reply to#1596572
On Fri, Mar 10, 2017 at 10:33:08AM +0800, Ye Xiaolong wrote:
> Previous kernel bug is gone for 10 times test of HEAD of tip/x86/asm. (f25d3847
> "x86/asm: Optimize clear_page()")
> 
> Tested-by: Xiaolong Ye <xiaolong.ye@intel.com>

Thanks for verifying!

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web