On Thu, Dec 05, 2013 at 01:22:19PM -0800, Christoph Hellwig wrote: > On Fri, Dec 06, 2013 at 08:10:47AM +1100, Dave Chinner wrote: > > Looks good, but can we add an assert to xfs_bunmapi() at the same > > time just to cover all the public bmapi interfaces with locking > > requirements? > > Sure, will do. > > Btw, I got another idea to sort this mess out a bit better: > > - add a new XFS_ILOCK_BMAP flag, and fold the bmap locking magic > into xfs_ilock. > - because the flag is now passed down we can assert that it is > passed in xfs_bmapi_read and friends even if the extent list > is already read in and thus improve coverage. Hmmm - I'm not sure I can see how that would work - the checks on lock mode look at the lock directly, not at some other flag register to indicate the locking context.... Are you thinking of expanding the code in xfs_isilocked() to handle this as well? And what do we do with the unlock case, as we can't tell after the fact from the inode state whether we locked shared or excl because the extent list has now been read in.... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
