On Fri, Dec 06, 2013 at 07:31:15AM +1100, Dave Chinner wrote: > On Thu, Dec 05, 2013 at 07:58:31AM -0800, Christoph Hellwig wrote: > > Signed-off-by: Christoph Hellwig <hch@xxxxxx> > > > > Index: xfs/fs/xfs/xfs_bmap_util.c > > =================================================================== > > --- xfs.orig/fs/xfs/xfs_bmap_util.c 2013-12-05 11:37:57.791685284 +0100 > > +++ xfs/fs/xfs/xfs_bmap_util.c 2013-12-05 11:39:43.599683113 +0100 > > @@ -1147,6 +1147,7 @@ xfs_zero_remaining_bytes( > > xfs_mount_t *mp = ip->i_mount; > > int nimap; > > int error = 0; > > + uint lock_mode; > > > > /* > > * Avoid doing I/O beyond eof - it's not necessary > > @@ -1159,11 +1160,15 @@ xfs_zero_remaining_bytes( > > if (endoff > XFS_ISIZE(ip)) > > endoff = XFS_ISIZE(ip); > > > > + lock_mode = xfs_ilock_map_shared(ip); > > + > > bp = xfs_buf_get_uncached(XFS_IS_REALTIME_INODE(ip) ? > > mp->m_rtdev_targp : mp->m_ddev_targp, > > BTOBB(mp->m_sb.sb_blocksize), 0); > > This now holds the ilock over data IO, which is not allowed to be > done as data IO completion can require the ilock to be taken. Yes, > the code specifically avoids all these problems, but the general > rule is that ilock is only held over metadata IO operations, not > data IO. If we need data IO serialisation, then we use the iolock. > > So, while this protects the extent tree, it also violates other > long-standing conventions for locking. Given that the code is > special, I'mnot opposed to making a special rule for this one > function, but it needs to be commented as to why this is a valid > thing to do in this function.... Maybe it would be better if the ilock could be taken and dropped within the loop. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
