[Top] [All Lists]

Re: FYI: xfstests generic/019 result panic. 4.0.0-rc5

To: Dmitry Monakhov <dmonakhov@xxxxxxxxxx>
Subject: Re: FYI: xfstests generic/019 result panic. 4.0.0-rc5
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Fri, 3 Apr 2015 09:43:10 +1100
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <87r3s2g3md.fsf@xxxxxxxxxx>
References: <87r3s2g3md.fsf@xxxxxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
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: 

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.


Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>