On Mon, Oct 28, 2019 at 05:17:05PM +0800, Ian Kent wrote: > Hi Darrick, > > Unfortunately I'm having a bit of trouble with my USB keyboard > and random key repeats, I lost several important messages this > morning due to it. > > Your report of the xfstests generic/361 problem was one of them > (as was Christoph's mail about the mount code location, I'll post > on that a bit later). So I'm going to have to refer to the posts > and hope that I can supply enough context to avoid confusion. > > Sorry about this. > > Anyway, you posted: > > "Dunno what's up with this particular patch, but I see regressions on > generic/361 (and similar asserts on a few others). The patches leading > up to this patch do not generate this error." > > I've reverted back to a point more or less before moving the mount > and super block handling code around and tried to reproduce the problem > on my test VM and I din't see the problem. > > Is there anything I need to do when running the test, other have > SCRATCH_MNT and SCRATCH_DEV defined in the local config, and the > mount point, and the device existing? Um... here's the kernel branch that I used: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=mount-api-crash Along with: MKFS_OPTIONS -- -m crc=0 MOUNT_OPTIONS -- -o usrquota,grpquota and both TEST_DEV and SCRATCH_DEV pointed at boring scsi disks. > This could have been a problem with the series I posted because > I did have some difficulty resolving some conflicts along the > way and may have made mistakes, hence reverting to earlier patches > (but also keeping the recent small pre-patch changes). Yeah, I had the same problem too; you might spot check the commits in there just in case /I/ screwed them up. (I would say 'or rebase on for-next' but (a) I don't know how Christoph's mount cleanups intermix with that and (b) let's see if this afternoon's for-next is less broken on s390 than this morning's was <frown>) --D > Ian >
