ffs: wait for trims earlier during unmount to avoid panic

[chs]

Summary

All softdep processing is supposed to be completed by
softdep_flushfiles() and no more deps are supposed to be created after
that, but if a pending trim completes after softdep_flushfiles() and
before softdep_unmount() then the blkfree that is performed by
ffs_blkfree_trim_task() will create a dep when none should exist, and
if softdep_unmount() is called before that dep is freed then the
kernel will panic. Prevent this by waiting for trims to complete
earlier in the unmount process, in ffs_flushfiles(), so that any deps
will be freed and any modified CG buffers will be flushed by the final
fsync of the devvp in ffs_flushfiles() as intended.

Sponsored by: Netflix

[mckusick]

I concur with the analysis. Waiting for trims in the current location is clearly too late. Waiting in the new location will ensure that all the dependencies get flushed. And once flushed it should not be possible to add any new ones thus no new trims should be able to appear.

[kib]

sys/ufs/ffs/ffs_vfsops.c

1428

I believe that the drain should be moved as well, otherwise e.g. um_trim_inflight_blks could be accessed after free.

Also, I would add an assert that um_trim_inflight == 0 there, before taskqueue_free()

[chs]

made requested changes.