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@xxxxxxxxxxxxx> > 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@xxxxxx> > Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx> > Signed-off-by: Ben Myers <bpm@xxxxxxx> 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@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
