Re: XFS on 3.14.0-rc1 (x86): xfs_isilocked() assertion on realtime subvolume

[Dave Chinner <david@fromorbit.com>]

On Sun, Feb 09, 2014 at 06:57:34PM -0500, Michael L. Semon wrote:
> Hi!  I was working with realtime subvolumes on a 3.14.0-rc1+ kernel, doing 
> something like this...
> 
> mkfs.xfs -l logdev=$TEST_LOGDEV -r rtdev=$TEST_RTDEV $TEST_DEV
> mount -t xfs -o logdev=$TEST_LOGDEV -o rtdev=$TEST_RTDEV $TEST_DEV $TEST_DIR
> 
> cd $TEST_DIR
> mkdir testrtdir
> xfs_io -c 'chattr +t' testrtdir
> cd testrtdir
> dd if=/dev/zero of=testrtfile bs=512 count=65536
> 
> ...and was greeted by this:
> 
> XFS: Assertion failed: xfs_isilocked(ip, XFS_ILOCK_SHARED|XFS_ILOCK_EXCL), file: fs/xfs/xfs_bmap.c, line: 4016
.....
> Call Trace:
>  [<7916e73c>] xfs_bmapi_read+0x89/0x39f
>  [<791b421d>] xfs_rtbuf_get+0x59/0x132
>  [<791b4860>] xfs_rtmodify_summary+0x64/0xcb
>  [<791b2742>] xfs_rtallocate_range+0xb4/0x17b
>  [<791b2a26>] xfs_rtallocate_extent_exact+0xa4/0xe8
>  [<791b2aee>] xfs_rtallocate_extent_near+0x84/0x317
>  [<791b3be1>] xfs_rtallocate_extent+0x1e9/0x233

OK, so there's a check in xfs_rtallocate_extent like this:

	ASSERT(xfs_isilocked(mp->m_rbmip, XFS_ILOCK_EXCL));

Which means we definitely have the bitmap inode locked at this
point, but we assert failed because we don't have the summary inode
locked when we go to modify it.

>From a production perspective, this won't matter as access is
already serialised by the lock on the bitmap inode, but we should
fix this for debug kernels.

I suspect that this means we'll need yet another lockdep context for
these inodes, becase we'll be nesting them in an order that doesn't
match any of the other nested inode locking, too.

Thanks for reporting the issue, Michael.

> A bisect brought me here:
> 
> root@plbearer:/usr/src/kernel-git/linux# git bisect good
> eef334e5776c8ef547ada4cec17549929fe590b4 is the first bad commit
> commit eef334e5776c8ef547ada4cec17549929fe590b4
> Author: Christoph Hellwig <hch@infradead.org>
> Date:   Fri Dec 6 12:30:17 2013 -0800
> 
>     xfs: assert that we hold the ilock for extent map access
> 
>     Make sure that xfs_bmapi_read has the ilock held in some way, and that
>     xfs_bmapi_write, xfs_bmapi_delay, xfs_bunmapi and xfs_iread_extents are
>     called with the ilock held exclusively.
> 
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
>     Reviewed-by: Dave Chinner <dchinner@redhat.com>
>     Signed-off-by: Ben Myers <bpm@sgi.com>

Yup, this is the second "regression" that has been exposed by this
patch. The first "regression" being a lockdep false positive, and
the second being this one....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs