From: Dave Chinner <david@fromorbit.com>
To: Dmitry Monakhov <dmonakhov@openvz.org>
Cc: xfs@oss.sgi.com
Subject: Re: FYI: xfstests generic/019 result panic. 4.0.0-rc5
Date: Fri, 3 Apr 2015 09:43:10 +1100 [thread overview]
Message-ID: <20150402224310.GG8465@dastard> (raw)
In-Reply-To: <87r3s2g3md.fsf@openvz.org>
On Thu, Apr 02, 2015 at 02:40:26PM +0300, Dmitry Monakhov wrote:
>
> Hi I've played with recent kernel 4.0.0-rc5 (AlViro's tree vfs.git/for-next)
>
> And have found two issues (I do not know whenever it was fixed in
> xfs.git already, so I just want to let you know)
> First one is Panic caused by xfstest generic/019 (disk failure
> simulation test) see attachment
.....
>
> generic/019 [13:30:32][ 17.619593] XFS (vdc): xlog_verify_grant_tail: space > BBTOB(tail_blocks)
> [ 41.914283] XFS (vdc): metadata I/O error: block 0x503d1f ("xlog_iodone") error 5 numblks 64
So the test has shut down the filesystem via device pull...
> [ 41.917326] XFS (vdc): xfs_bmap_check_leaf_extents: BAD after btree leaves for 6623 extents
in the middle of a bmbt update operation, which aborted in an
inconsistent state in memory due to shutdown...
> [ 41.917376] XFS (vdc): Log I/O Error Detected. Shutting down filesystem
> [ 41.917378] XFS (vdc): Please umount the filesystem and rectify the problem(s)
> [ 41.918098] fsstress (3180) used greatest stack depth: 11392 bytes left
> [ 41.918876] XFS (vdc): metadata I/O error: block 0x503d5f ("xlog_iodone") error 5 numblks 64
> [ 41.918966] XFS (vdc): xfs_log_force: error -5 returned.
> [ 41.930237] Kernel panic - not syncing: xfs_bmap_check_leaf_extents: CORRUPTED BTREE OR SOMETHING
And debug code detected that inconsistent in-memory state, and threw
out the panic. Production machines won't run this code (it's
CONFIG_XFS_DEBUG=y specific) so they'll just shut down normally.
> Second one is lockdep's complain from splice, It looks like a false-positive one, but still.
No, that's a real one. splice has inverted locks and we've been able
to deadlock it since, well, forever. The recent rework that Al Viro
did removed the old lock inversion problem, and created a new one
w.r.t. to the pipe_lock and filesystem locks. I've reported this to
him previously, but I've never got any response about it...
Thanks for the reports, though, Dmitry.
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:[~2015-04-02 22:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-02 11:40 FYI: xfstests generic/019 result panic. 4.0.0-rc5 Dmitry Monakhov
2015-04-02 22:43 ` 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=20150402224310.GG8465@dastard \
--to=david@fromorbit.com \
--cc=dmonakhov@openvz.org \
--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