On Mon, Feb 06, 2017 at 11:49:24AM -0500, Brian Foster wrote: > > Can you explain in which contex you mean this? I'm a bit lost on this > > comment unfortunately. > > Sorry.. what I'm concerned about is waiting on in-flight discards during > unmount. The current discard code issues the discards synchronously and > so the log force is sufficient to drain in-flight I/O before we start > breaking down core data structures in the unmount path that would be > referenced by end_io handlers and such. > > With this change, the log force can return with discards still in > flight. In fact, a subsequent flush of the workqueue is not sufficient > since there's no guarantee the work item has been queued by that point > either. If we don't have unmount serialization against in-flight I/Os, > this can lead to unmount crashes (see the I/O accounting infrastructure > added in commit 9c7504aa7 for an example of this problem with async > buffer I/Os). Am I missing something that protects us from this problem > here? No, you're right. We should have a xfs_extent_busy_flush_all call in the unmount path. I'll resend the series again with that added. -- 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
