On Fri, Mar 18, 2022 at 02:51:33PM -0700, Darrick J. Wong wrote: > On Sat, Mar 19, 2022 at 08:48:31AM +1100, Dave Chinner wrote: > > On Fri, Mar 18, 2022 at 09:46:53AM -0400, Brian Foster wrote: > > > Hi, > > > > > > I'm not sure if this is known and/or fixed already, but it didn't look > > > familiar so here is a report. I hit a splat when testing Willy's > > > prospective folio bookmark change and it turns out it replicates on > > > Linus' current master (551acdc3c3d2). This initially reproduced on > > > xfs/264 (mkfs defaults) and I saw a soft lockup warning variant via > > > xfs/006, but when I attempted to reproduce the latter a second time I > > > hit what looks like the same problem as xfs/264. Both tests seem to > > > involve some form of error injection, so possibly the same underlying > > > problem. The GPF splat from xfs/264 is below. > > > > On a side note, I'm wondering if we should add xfs/006 and xfs/264 > > to the recoveryloop group - they do a shutdown under load and a > > followup mount to ensure the filesystem gets recovered before > > the test ends and the fs is checked, so while thy don't explicitly > > test recovery, they do exercise it.... > > > > Thoughts? > > Someone else asked about this the other day, and I proposed a 'recovery' > group for tests that don't run in a loop. That distinction is largely meaningless to me. I tend to think of "recoveryloop" as the recovery tests I want to run in a long running loop via iteration. e.g. isomething like 'check -I 250 -g recoveryloop'. I don't really care if the tests loop internally doing multiple recoveries - I'm wanting to run the recovery tests that reproduce problems frequeently in a tight loop repeatedly. Hence I think we should just lump the shutdown+recovery tests all in one group so that when we want to exercise shutdown/recovery we just have one single group to run repeatedly in a loop. Whether that group is named 'recovery' or 'recoveryloop' is largely irrelevant to me. Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx
