From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760598AbYGQTGM (ORCPT ); Thu, 17 Jul 2008 15:06:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1757932AbYGQTF5 (ORCPT ); Thu, 17 Jul 2008 15:05:57 -0400 Received: from mx1.redhat.com ([66.187.233.31]:41387 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757678AbYGQTF5 (ORCPT ); Thu, 17 Jul 2008 15:05:57 -0400 Message-ID: <487F980F.7070708@redhat.com> Date: Thu, 17 Jul 2008 14:05:51 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Vegard Nossum CC: Tim Shimmin , xfs@oss.sgi.com, linux-kernel@vger.kernel.org, Johannes Weiner Subject: Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54! References: <19f34abd0807171046j425bebc6m8d8eb80a641e0e5b@mail.gmail.com> In-Reply-To: <19f34abd0807171046j425bebc6m8d8eb80a641e0e5b@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Vegard Nossum wrote: > Hi, > > I got this with an intentionally corrupted filesystem: > > Filesystem "loop1": Disabling barriers, not supported by the underlying device > XFS mounting filesystem loop1 > Ending clean XFS mount for filesystem: loop1 > Device loop1 - bad inode magic/vsn daddr 9680 #30 (magic=4946) > ------------[ cut here ]------------ > kernel BUG at fs/xfs/support/debug.c:54! running a debug XFS will turn all sorts of tests into panics that would not otherwise crash and burn that way. I think normally when testing intentionally corrupted filesystems, you expect corruptions to be handled gracefully. But in xfs's flavor of debug, I'm not sure it's quite as true. Perhaps the debug variant should not BUG() on disk corruption either, but it'd probably be more relevent to test this on a non-debug build. Does this corrupted fs survive better on non-debug xfs? -Eric > invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC > Pid: 12849, comm: grep Not tainted (2.6.26-03414-g33af79d #43) > EIP: 0060:[] EFLAGS: 00210246 CPU: 1 > EIP is at cmn_err+0x99/0xa0 > EAX: ed75e000 EBX: c089047c ECX: ed75e000 EDX: 00000000 > ESI: 00000000 EDI: 00200286 EBP: ed75fbbc ESP: ed75fba4 > DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 > Process grep (pid: 12849, ti=ed75e000 task=f1ee9fe0 task.ti=ed75e000) > Stack: c0855099 c0846a0d c0d0e8c0 00004946 df92a8f0 0000001e ed75fc2c c03540d4 > 00000000 c089047c ed75fbfc 000025d0 00000000 0000001e 00004946 ed75fc54 > 00000000 df92a8f0 df92abd8 000025d0 00000000 00000000 706f6f6c 00000031 > Call Trace: > [] ? xfs_imap_to_bp+0x164/0x250 > [] ? trace_hardirqs_on_caller+0x116/0x170 > [] ? xfs_itobp+0x90/0x180 > [] ? xfs_iread+0xa1/0x280 > [] ? xfs_iget_core+0x1c6/0x6e0 > [] ? xfs_iget+0xfa/0x170 > [] ? xfs_lookup+0xb6/0xc0 > [] ? xfs_vn_lookup+0x4a/0x90 > [] ? do_lookup+0x160/0x1b0 > [] ? __link_path_walk+0x208/0xdc0 > [] ? up_read+0x16/0x30 > [] ? xfs_iunlock+0xee/0x110 > [] ? xfs_vn_follow_link+0x3f/0x80 > [] ? __link_path_walk+0x8f7/0xdc0 > [] ? trace_hardirqs_off+0xb/0x10 > [] ? path_walk+0x54/0xb0 > [] ? do_path_lookup+0x85/0x230 > [] ? __user_walk_fd+0x38/0x50 > [] ? vfs_stat_fd+0x21/0x50 > [] ? put_lock_stats+0xd/0x30 > [] ? mntput_no_expire+0x1d/0x110 > [] ? vfs_stat+0x11/0x20 > [] ? sys_stat64+0x14/0x30 > [] ? fput+0x1f/0x30 > [] ? trace_hardirqs_on_thunk+0xc/0x10 > [] ? trace_hardirqs_on_caller+0x116/0x170 > [] ? trace_hardirqs_on_thunk+0xc/0x10 > [] ? sysenter_past_esp+0x78/0xc5 > ======================= > Code: 04 e8 00 eb 3d 00 89 fa b8 40 4a 92 c0 e8 70 d0 3d 00 85 f6 74 > 15 83 c4 0c 5b 5e 5f 5d c3 8d 74 26 00 c6 81 c0 e8 d0 c0 00 eb bc <0f> > 0b eb fe 90 90 90 55 b9 04 00 00 00 89 e5 57 89 c7 31 c0 f3 > EIP: [] cmn_err+0x99/0xa0 SS:ESP 0068:ed75fba4 > Kernel panic - not syncing: Fatal exception > > > Vegard >