From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751563AbdCICUD (ORCPT ); Wed, 8 Mar 2017 21:20:03 -0500 Received: from mga06.intel.com ([134.134.136.31]:38169 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751390AbdCICUC (ORCPT ); Wed, 8 Mar 2017 21:20:02 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.36,266,1486454400"; d="scan'208";a="942249565" Date: Thu, 9 Mar 2017 10:13:10 +0800 From: Ye Xiaolong To: Borislav Petkov Cc: X86 ML , Andy Lutomirski , Peter Zijlstra , LKML , lkp@01.org, Fengguang Wu Subject: Re: [lkp-robot] [x86] ed3ce2a917: BUG:unable_to_handle_kernel Message-ID: <20170309021310.GB11500@yexl-desktop> References: <20170215111927.emdgxf2pide3kwro@pd.tnic> <20170302010934.GI9855@yexl-desktop> <20170302181957.533r5g2feoc53jtq@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170302181957.533r5g2feoc53jtq@pd.tnic> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: [] 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.