On Tue, Oct 25, 2016 at 01:33:12PM -0400, Brian Foster wrote: > On Tue, Oct 18, 2016 at 02:26:15PM -0400, Brian Foster wrote: > > Filesystem shutdown testing on an older distro kernel has uncovered an > > imbalanced locking pattern for the inode flush lock in > > xfs_reclaim_inode(). Specifically, there is a double unlock sequence > > between the call to xfs_iflush_abort() and xfs_reclaim_inode() at the > > "reclaim:" label. > > > > This actually does not cause obvious problems on current kernels due to > > the current flush lock implementation. Older kernels use a counting > > based flush lock mechanism, however, which effectively breaks the lock > > indefinitely when an already unlocked flush lock is repeatedly unlocked. > > Though this only currently occurs on filesystem shutdown, it has > > reproduced the effect of elevating an fs shutdown to a system-wide crash > > or hang. > > > > As it turns out, the flush lock is not actually required for the reclaim > > logic in xfs_reclaim_inode() because by that time we have already cycled > > the flush lock once while holding ILOCK_EXCL. Therefore, remove the > > additional flush lock/unlock cycle around the 'reclaim:' label and > > update branches into this label to release the flush lock where > > appropriate. Add an assert to xfs_ifunlock() to help prevent future > > occurences of the same problem. > > > > Signed-off-by: Brian Foster <bfoster@xxxxxxxxxx> > > Reported-by: Zorro Lang <zlang@xxxxxxxxxx> > > --- > > ping? not had a chance to context switch back to this. Once I've got the reflink userspace stuff sorted, I'll switch back to kernel stuff... Cheers, Dave. -- Dave Chinner david@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
