public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@redhat.com>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: Tim Shimmin <xfs-masters@oss.sgi.com>,
	xfs@oss.sgi.com, linux-kernel@vger.kernel.org,
	Johannes Weiner <hannes@saeurebad.de>
Subject: Re: latest -git: kernel BUG at fs/xfs/support/debug.c:54!
Date: Thu, 17 Jul 2008 14:05:51 -0500	[thread overview]
Message-ID: <487F980F.7070708@redhat.com> (raw)
In-Reply-To: <19f34abd0807171046j425bebc6m8d8eb80a641e0e5b@mail.gmail.com>

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:[<c0386d89>] 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:
>  [<c03540d4>] ? xfs_imap_to_bp+0x164/0x250
>  [<c015ad76>] ? trace_hardirqs_on_caller+0x116/0x170
>  [<c0354250>] ? xfs_itobp+0x90/0x180
>  [<c0356e51>] ? xfs_iread+0xa1/0x280
>  [<c034f216>] ? xfs_iget_core+0x1c6/0x6e0
>  [<c034f82a>] ? xfs_iget+0xfa/0x170
>  [<c0377546>] ? xfs_lookup+0xb6/0xc0
>  [<c0382fba>] ? xfs_vn_lookup+0x4a/0x90
>  [<c01ac110>] ? do_lookup+0x160/0x1b0
>  [<c01adc38>] ? __link_path_walk+0x208/0xdc0
>  [<c014f916>] ? up_read+0x16/0x30
>  [<c034eabe>] ? xfs_iunlock+0xee/0x110
>  [<c0382bdf>] ? xfs_vn_follow_link+0x3f/0x80
>  [<c01ae327>] ? __link_path_walk+0x8f7/0xdc0
>  [<c015906b>] ? trace_hardirqs_off+0xb/0x10
>  [<c01ae844>] ? path_walk+0x54/0xb0
>  [<c01aea45>] ? do_path_lookup+0x85/0x230
>  [<c01af7a8>] ? __user_walk_fd+0x38/0x50
>  [<c01a7fb1>] ? vfs_stat_fd+0x21/0x50
>  [<c01590cd>] ? put_lock_stats+0xd/0x30
>  [<c01bc81d>] ? mntput_no_expire+0x1d/0x110
>  [<c01a8081>] ? vfs_stat+0x11/0x20
>  [<c01a80a4>] ? sys_stat64+0x14/0x30
>  [<c01a5a8f>] ? fput+0x1f/0x30
>  [<c044a0f8>] ? trace_hardirqs_on_thunk+0xc/0x10
>  [<c015ad76>] ? trace_hardirqs_on_caller+0x116/0x170
>  [<c044a0f8>] ? trace_hardirqs_on_thunk+0xc/0x10
>  [<c010407f>] ? 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: [<c0386d89>] cmn_err+0x99/0xa0 SS:ESP 0068:ed75fba4
> Kernel panic - not syncing: Fatal exception
> 
> 
> Vegard
> 


  reply	other threads:[~2008-07-17 19:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-17 17:46 latest -git: kernel BUG at fs/xfs/support/debug.c:54! Vegard Nossum
2008-07-17 19:05 ` Eric Sandeen [this message]
2008-07-17 19:18   ` Vegard Nossum
2008-07-17 19:29     ` Vegard Nossum
2008-07-17 22:40       ` Dave Chinner
2008-07-19 13:16         ` Vegard Nossum

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=487F980F.7070708@redhat.com \
    --to=sandeen@redhat.com \
    --cc=hannes@saeurebad.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vegard.nossum@gmail.com \
    --cc=xfs-masters@oss.sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox