mirror of
https://github.com/versity/scoutfs.git
synced 2026-02-08 03:30:46 +00:00
6adb24f0f52291b81d3a770d83646efb08f4f638
We're seeing warnings from trying to destroy the server work queue while it's still active. Auditing shows that almost all of the sources of queued work are shutdown before we destroy the work queue. Except for the compaction func. It queues itself via the sneaky call to scoutfs_compact_kick() inside scoutfs_client_finish_compaction(). What a mess. We only wait for work to finish running in scoutfs_compact_destroy(), we don't forbid further queueing. So with just the right races it looks possible to have the compact func executing after we return from _destroy(). It can then later try to queue the commit_work in the server workqueue. It's pretty hard to imagine this race, but it's made a bit easier by the startling fact that we don't free the compact info struct. That makes it a little easier to imagine use-after-destroy not exploding. So let's forcibly forbid chain queueing during compaction shutdown by using cancel_work_sync(). It marks the work canceling while flushing so the queue_work in the work func won't do anything. This should ensure that the compaction func isn't running when destroy returns. Also while we're at it actually free the allocated compaction info struct! Cool cool cool. Signed-off-by: Zach Brown <zab@versity.com>
Description
No description provided
Languages
C
87%
Shell
9.3%
Roff
2.5%
TeX
0.8%
Makefile
0.4%