From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753226AbcEYG3D (ORCPT ); Wed, 25 May 2016 02:29:03 -0400 Received: from mail-wm0-f68.google.com ([74.125.82.68]:34929 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750797AbcEYG3B (ORCPT ); Wed, 25 May 2016 02:29:01 -0400 Date: Wed, 25 May 2016 08:28:15 +0200 From: Ingo Molnar To: Dave Jones , kernel test robot , Borislav Petkov , LKP , oprofile-list@lists.sf.net, linux-kernel@vger.kernel.org, wfg@linux.intel.com Subject: Re: [x86/cpufeature] 7b5e74e637: BUG: unable to handle kernel paging request at 6b636170 Message-ID: <20160525062815.GA31368@gmail.com> References: <5744b252.TKkyCAKRsZqh/9JL%fengguang.wu@intel.com> <20160524200709.GA9079@codemonkey.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160524200709.GA9079@codemonkey.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Dave Jones wrote: > On Wed, May 25, 2016 at 03:58:10AM +0800, kernel test robot wrote: > > > 0day kernel testing robot got the below dmesg and the first bad commit is > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > > > commit 7b5e74e637e4a977c7cf40fd7de332f60b68180e > > Author: Borislav Petkov > > AuthorDate: Tue Mar 29 17:41:54 2016 +0200 > > Commit: Ingo Molnar > > CommitDate: Thu Mar 31 13:33:17 2016 +0200 > > > > x86/cpufeature: Remove cpu_has_arch_perfmon > > > > Use boot_cpu_has() instead. > > This seem an unlikely candidate given... > > > [ 1.914984] random: trinity urandom read with 25 bits of entropy available > > [ 8.542178] random: nonblocking pool is initialized > > [ 11.939833] sock: process `trinity-main' is using obsolete setsockopt SO_BSDCOMPAT > > [ 12.349890] BUG: unable to handle kernel paging request at 6b636170 > > [ 12.349895] IP: [] perf_prepare_sample+0x7d/0x263 > > The trace is more related to perf. Also, 7b5e74e637e4a appears to be pretty much a provable NOP, it should not change a single byte in the kernel image, as it replaces a macro use: -#define cpu_has_arch_perfmon boot_cpu_has(X86_FEATURE_ARCH_PERFMON) ... with open-coded expressions of the same. Thanks, Ingo