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.
|