From: Dave Chinner <david@fromorbit.com>
To: Mark Tinguely <tinguely@sgi.com>
Cc: "Michael L. Semon" <mlsemon35@gmail.com>, xfs@oss.sgi.com
Subject: Re: xfstests #111 + XFS debug = infinite-loop oops
Date: Wed, 13 Mar 2013 08:11:01 +1100 [thread overview]
Message-ID: <20130312211101.GQ21651@dastard> (raw)
In-Reply-To: <513F8FBD.4080805@sgi.com>
On Tue, Mar 12, 2013 at 03:27:41PM -0500, Mark Tinguely wrote:
> On 03/12/13 13:46, Michael L. Semon wrote:
> >Hi! I was running xfstests #111 under the following conditions...
> >
> >(*) zeroed partitions, and
> >(*) a fresh mkfs.xfs for each file system, and
> >
> >(1) CONFIG_XFS_DEBUG used, rtdev used, external logdev used, or
> >(2) CONFIG_XFS_DEBUG used, external logdev used, or
> >(3) CONFIG_XFS_DEBUG used, all internal, mkfs.xfs called with no options
> >
> >...and I get a trace like the one below (from (3)). The trace is from
> >kernel 3.9.0-rc2 on an old Pentium III, using a normal VGA console on
> >the test PC, captured by another PC over serial cable. The trace is
> >part of an infinite loop that becomes finite only if I rip out the
> >console and VGA entirely. Overall, more is in play here than just
> >XFS, but I don't know to whom I should write. [A relevant question
> >for which I don't know the answer: Are there critical sections where
> >you should not use assertions or call BUG() in debug code?] Something
> >in XFS debug is fighting the console/VGA/framebuffer system, and I
> >don't know where to go from here.
> >
> >You'll know you've reproduced this one because you'll need the power
> >button to shut the PC off, so be careful.
> >
> >This is crash report; no fix is requested. I'm using the simple
> >workarounds "don't run xfstests #111 with XFS debugging enabled" and
> >"Backups! Backups! Backups!" All is well.
> >
> >Thanks!
> >
> >Michael
> >
> >[ 1399.347056] XFS (sda12): Corruption detected. Unmount and run xfs_repair
> >[ 1399.353815] XFS (sda12): bad inode magic/vsn daddr 64 #8 (magic=5858)
>
> 0x58 == 'X'
>
> >[ 1399.360277] XFS: Assertion failed: 0, file: fs/xfs/xfs_inode.c, line: 416
>
> Thanks for the report, but there is no bug here. Maybe we should
> list test 111 as "dangerous".
Don't think so - do we actually need that assert in the verifier?
The test is actaully checking that we don't end up with an endless
loop in bulkstat when corruption is hit, so we should really make
sure the test can perform it's functions on CONFIG_XFS_DEBUG=y
kernels...
> The inode verifiers are doing their job.
Well, they aren't supposed to crash the kernel. The debug check is
historic behaviour that we can probably now remove...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2013-03-12 21:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-12 18:46 xfstests #111 + XFS debug = infinite-loop oops Michael L. Semon
2013-03-12 20:27 ` Mark Tinguely
2013-03-12 21:11 ` Dave Chinner [this message]
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=20130312211101.GQ21651@dastard \
--to=david@fromorbit.com \
--cc=mlsemon35@gmail.com \
--cc=tinguely@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