https://bugzilla.kernel.org/show_bug.cgi?id=206397 --- Comment #3 from bfoster@xxxxxxxxxx --- On Tue, Feb 04, 2020 at 05:10:05PM +0000, bugzilla-daemon@xxxxxxxxxxxxxxxxxxx wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=206397 > > --- Comment #2 from Zorro Lang (zlang@xxxxxxxxxx) --- > (In reply to Chandan Rajendra from comment #1) > > I was unable to recreate this issue on a ppc64le kvm guest. I used Linux > > v5.5 and xfsprogs' for-next branch. > > > > Can you please share the kernel config file? Also, Can you please tell me > > how easy is it recreate this bug? > > It's really hard to reproduce. The g/475 is a random test, it's helped us to > find many different issues. For this bug, this's the 1st time I hit it, and > can't reproduce it simply. > Have you still been unable to reproduce (assuming you've been attempting to)? How many iterations were required before you reproduced the first time? I'm wondering if the XLOG_STATE_IOERROR check in xfs_log_release_iclog() is racy with respect to filesystem shutdown. There's an ASSERT_ALWAYS() earlier in this (xlog_cil_push()) codepath that checks for ACTIVE || WANT_SYNC and it doesn't appear that has failed from your output snippet. The aforementioned IOERROR check occurs before we acquire ->l_icloglock, however, which I think means xfs_log_force_umount() could jump in if called from another task and reset all of the iclogs while the release path waits on the lock. Brian > -- > You are receiving this mail because: > You are watching the assignee of the bug. > -- You are receiving this mail because: You are watching the assignee of the bug.
