Thanks for the response Dave. On Fri, 2011-02-25 at 13:06 +1100, Dave Chinner wrote: > On Thu, Feb 24, 2011 at 01:54:40PM -0800, Chandra Seetharaman wrote: > > Hello, > > > > I ran the xfs tests on my POWER box and was tripped by an ASSERT while > > running test 011. I have not seen it before in 2.6.37, so started with a > > git-bisect from 2.6.37 to 2.6.38-rc6 and ended at this commit: > > -------------------- > > Author Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > > Tue, 11 Jan 2011 19:42:06 +0000 (11:42 -0800) > > committer Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > > Tue, 11 Jan 2011 19:42:06 +0000 (11:42 -0800) > > commit 7bc4a4ce68f8c6d064ea949446852e996526f692 > > Merge branch 'for-linus-merged' of git://oss.sgi.com/xfs/xfs > > > > * 'for-linus-merged' of git://oss.sgi.com/xfs/xfs: (47 commits) > > xfs: convert grant head manipulations to lockless algorithm > > xfs: introduce new locks for the log grant ticket wait queues > > xfs: convert log grant heads to atomic variables > > xfs: convert l_tail_lsn to an atomic variable. > > xfs: convert l_last_sync_lsn to an atomic variable > > xfs: make AIL tail pushing independent of the grant lock > > xfs: use wait queues directly for the log wait queues > > xfs: combine grant heads into a single 64 bit integer > > xfs: rework log grant space calculations > > xfs: fact out common grant head/log tail verification code > > xfs: convert log grant ticket queues to list heads > > xfs: use AIL bulk delete function to implement single delete > > xfs: use AIL bulk update function to implement single updates > > xfs: remove all the inodes on a buffer from the AIL in bulk > > xfs: consume iodone callback items on buffers as they are processed > > xfs: reduce the number of AIL push wakeups > > xfs: bulk AIL insertion during transaction commit > > xfs: clean up xfs_ail_delete() > > xfs: Pull EFI/EFD handling out from under the AIL lock > > xfs: fix EFI transaction cancellation. > > ... > > ----------------------------- > > > > Since it included so many patches, I thought i will start a git-bisect > > on xfs git tree at git://oss.sgi.com/xfs/xfs, and ended up at > > 92f1c008ae79e32b83c0607d184b194f302bb3ee, which is the same commit as > > above. > > you landed on the the merge commit. mark that commit as bad, and the > bisect should continue down the merged branch. Otherwise you could > try skipping the merge commit and again the bisect should continue > down the branch. I will try that route and see. > > Two questions: > > 1. Has anybody seen this problem ? I see this ASSERT has been added in > > that patch set, is it a false-positive ? > > The ASSERT() being triggered is racy. We are comparing the state of > two different atomic variables that are updated without > synchronisation. Hence after sampling the first, the second could be > changed before it is sampled and hence cause the assert to fail. > > I've never seen it be triggered, so I'm interested to know if this > is reproducable (i.e. a real problem) or whether it is a false > trigger (i.e. update race). It is consistently reproducible. it _always_ fails with that commit in my POWER hardware. > > Cheers, > > Dave. _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
