From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751833Ab3KSHGt (ORCPT ); Tue, 19 Nov 2013 02:06:49 -0500 Received: from mail-ee0-f49.google.com ([74.125.83.49]:44111 "EHLO mail-ee0-f49.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751809Ab3KSHGr (ORCPT ); Tue, 19 Nov 2013 02:06:47 -0500 Date: Tue, 19 Nov 2013 08:06:44 +0100 From: Ingo Molnar To: Vince Weaver Cc: One Thousand Gnomes , Peter Zijlstra , LKML , Paul Mackerras , Arnaldo Carvalho de Melo , tytso@mit.edu, adilger.kernel@dilger.ca Subject: Re: perf bug: bad page map Message-ID: <20131119070644.GE32367@gmail.com> References: <20131118151746.GC10022@twins.programming.kicks-ass.net> <20131118230553.32c478df@alan.etchedpixels.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 * Vince Weaver wrote: > On Mon, 18 Nov 2013, One Thousand Gnomes wrote: > > > On Mon, 18 Nov 2013 11:41:22 -0500 (EST) > > Vince Weaver wrote: > > > > > On Mon, 18 Nov 2013, Peter Zijlstra wrote: > > > > > > > On Fri, Nov 15, 2013 at 01:04:23PM -0500, Vince Weaver wrote: > > > > > > > > > > (figured out the minicom issue). > > > > > > > > > > Anyway while trying to reproduce the last bug I instead got this with > > > > > the perf_fuzzer. > > > > > > > > > > Is it worth continuing to run and report these issues? I'm losing track > > > > > of all the open bugs. > > > > > > > > This is looks like ext4. Not entirely sure how perf ties into this. > > > > > > It's believable the filesystem could have issues (it's a fuzzer machine, > > > so it's had 100+ unclean shutdowns on an SSD drive in the past few months) > > > but as far as I know there shouldn't have been any filesystem accesses > > > happening at all when the bug triggered. > > > > Obvious question - does it pass fsck currently. If it does then > > presumably it was sane at the time it went pop ? > > # e2fsck -f /dev/sda1 > e2fsck 1.42.8 (20-Jun-2013) > Pass 1: Checking inodes, blocks, and sizes > Pass 2: Checking directory structure > Pass 3: Checking directory connectivity > Pass 4: Checking reference counts > Pass 5: Checking group summary information > /dev/sda1: 620972/3514368 files (0.5% non-contiguous), 9796212/14047744 blocks > > so it looks clean now... Also, in no way should a corrupted filesystem be able to provoke kernel crashes. So even if the filesystem had errors, this would still be a kernel bug we need to fix. Thanks, Ingo