On Wed, Jul 20, 2016 at 09:56:26PM -0700, Darrick J. Wong wrote: > When we're deleting realtime extents, we need to lock the summary > inode in case we need to update the summary info to prevent an assert > on the rsumip inode lock on a debug kernel. While we're at it, fix > the locking annotations so that we avoid triggering lockdep warnings. > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > --- I haven't tried the rt stuff in quite some time (and even then never really played with it much). What's the assert that fails? Brian > fs/xfs/libxfs/xfs_bmap.c | 4 +++- > fs/xfs/xfs_bmap_util.c | 4 ++-- > 2 files changed, 5 insertions(+), 3 deletions(-) > > > diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c > index 2f2c85c..c5981f4 100644 > --- a/fs/xfs/libxfs/xfs_bmap.c > +++ b/fs/xfs/libxfs/xfs_bmap.c > @@ -5179,8 +5179,10 @@ xfs_bunmapi( > /* > * Synchronize by locking the bitmap inode. > */ > - xfs_ilock(mp->m_rbmip, XFS_ILOCK_EXCL); > + xfs_ilock(mp->m_rbmip, XFS_ILOCK_EXCL|XFS_ILOCK_RTBITMAP); > xfs_trans_ijoin(tp, mp->m_rbmip, XFS_ILOCK_EXCL); > + xfs_ilock(mp->m_rsumip, XFS_ILOCK_EXCL|XFS_ILOCK_RTSUM); > + xfs_trans_ijoin(tp, mp->m_rsumip, XFS_ILOCK_EXCL); > } > > extno = 0; > diff --git a/fs/xfs/xfs_bmap_util.c b/fs/xfs/xfs_bmap_util.c > index cd4a850..998c3e6 100644 > --- a/fs/xfs/xfs_bmap_util.c > +++ b/fs/xfs/xfs_bmap_util.c > @@ -214,9 +214,9 @@ xfs_bmap_rtalloc( > /* > * Lock out modifications to both the RT bitmap and summary inodes > */ > - xfs_ilock(mp->m_rbmip, XFS_ILOCK_EXCL); > + xfs_ilock(mp->m_rbmip, XFS_ILOCK_EXCL|XFS_ILOCK_RTBITMAP); > xfs_trans_ijoin(ap->tp, mp->m_rbmip, XFS_ILOCK_EXCL); > - xfs_ilock(mp->m_rsumip, XFS_ILOCK_EXCL); > + xfs_ilock(mp->m_rsumip, XFS_ILOCK_EXCL|XFS_ILOCK_RTSUM); > xfs_trans_ijoin(ap->tp, mp->m_rsumip, XFS_ILOCK_EXCL); > > /* > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
