On Fri, Apr 08, 2016 at 07:37:09AM -0400, Brian Foster wrote: > On Fri, Apr 08, 2016 at 11:28:41AM +0800, Eryu Guan wrote: > > On Fri, Apr 08, 2016 at 09:37:45AM +1000, Dave Chinner wrote: > > > Hi folks, > > > > > > This is the second version of this patch set, first posted and > > > described here: > > > > > > http://oss.sgi.com/archives/xfs/2016-04/msg00069.html > > > > Just a quick note here, I'm testing the v1 patchset right now, v4.6-rc2 > > kernel + v1 patch, config file is based on rhel7 debug kernel config. > > > > The test is the same as the original reproducer (long term fsstress run > > on XFS, exported from NFS). The test on x86_64 host has been running for > > two days and everything looks fine. Test on ppc64 host has been running > > for a few hours and I noticed a lock issue and a few warnings, not sure > > if it's related to the patches or even to XFS yet(I need to run test on > > stock -rc2 kernel to be sure), but just post the logs here for reference > > > > Had the original problem ever been reproduced on an upstream kernel? No, I've never seen the original problem in my upstream kernel testings. Perhaps that's because I didn't run tests on debug kernels. But I didn't see it in RHEL7 debug kernel testings either. > > FWIW, my rhel kernel based test is still running well approaching ~48 > hours. I've seen some lockdep messages (bad unlock balance), but IIRC > I've been seeing those from the start so I haven't been paying much > attention to it while digging into the core problem. > > > [ 1911.626286] ====================================================== > > [ 1911.626291] [ INFO: possible circular locking dependency detected ] > > [ 1911.626297] 4.6.0-rc2.debug+ #1 Not tainted > > [ 1911.626301] ------------------------------------------------------- > > [ 1911.626306] nfsd/7402 is trying to acquire lock: > > [ 1911.626311] (&s->s_sync_lock){+.+.+.}, at: [<c0000000003585f0>] .sync_inodes_sb+0xe0/0x230 > > [ 1911.626327] > > [ 1911.626327] but task is already holding lock: > > [ 1911.626333] (sb_internal){.+.+.+}, at: [<c00000000031a780>] .__sb_start_write+0x90/0x130 > > [ 1911.626346] > > [ 1911.626346] which lock already depends on the new lock. > > [ 1911.626346] > > [ 1911.626353] > > [ 1911.626353] the existing dependency chain (in reverse order) is: > > [ 1911.626358] > ... > > [ 1911.627134] Possible unsafe locking scenario: > > [ 1911.627134] > > [ 1911.627139] CPU0 CPU1 > > [ 1911.627143] ---- ---- > > [ 1911.627147] lock(sb_internal); > > [ 1911.627153] lock(&s->s_sync_lock); > > [ 1911.627160] lock(sb_internal); > > [ 1911.627166] lock(&s->s_sync_lock); > > [ 1911.627172] > > [ 1911.627172] *** DEADLOCK *** > > [ 1911.627172] > ... > > We actually have a report of this one on the list: > > http://oss.sgi.com/archives/xfs/2016-04/msg00001.html > > ... so I don't think it's related to this series. I believe I've seen > this once or twice when testing something completely unrelated, as well. > > > [ 2046.852739] kworker/dying (399) used greatest stack depth: 4352 bytes left > > [ 2854.687381] XFS: Assertion failed: buffer_mapped(bh), file: fs/xfs/xfs_aops.c, line: 780 > > [ 2854.687434] ------------[ cut here ]------------ > > [ 2854.687488] WARNING: CPU: 5 PID: 28924 at fs/xfs/xfs_message.c:105 .asswarn+0x2c/0x40 [xfs] > ... > > [ 2854.687997] ---[ end trace 872ac2709186f780 ]--- > > These asserts look new to me, however. It would be interesting to see if > these reproduce independently. I've seen just the assert failures in the same fsstress testing on ppc64 host (no lock warnings in the beginning). Will see if it's still reproducible on stock kernel. Thanks, Eryu _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
