Message-ID: <20170309021310.GB11500@yexl-desktop>
Date:   Thu, 9 Mar 2017 10:13:10 +0800
From:   Ye Xiaolong <xiaolong.ye@...el.com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     X86 ML <x86@...nel.org>, Andy Lutomirski <luto@...capital.net>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>, lkp@...org,
        Fengguang Wu <fengguang.wu@...el.com>
Subject: Re: [lkp-robot] [x86]  ed3ce2a917: BUG:unable_to_handle_kernel

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.

Powered by blists - more mailing lists