rclone/vfs/vfscache
Leo Luan 5f1d5a1897 vfs: Fix a deadlock vulnerability in downloaders.Close
The downloaders.Close() call acquires the downloaders' mutex before
calling the wait group wait and the main downloaders thread has a
periodical (5 seconds interval) call to kick its waiters and the
waiter dispatch function tries to get the mutex. So a deadlock can
occur if the Close() call starts, gets the mutex, while the main
downloader thread already got the timer's tick and proceeded to
call kickWaiters. The deadlock happens when the Close call gets
the mutex between the timer's kick and the main downloader thread
gets the mutex first. So it's a pretty short period of time and
it probably explains why the problem has not surfaced, maybe
something like tens of nanoseconds out of 5 seconds (~10^^-8).
It took 5 days of continued stressing the Close calls for the
deadlock to appear.
2020-10-06 16:35:23 +01:00
..
downloaders vfs: Fix a deadlock vulnerability in downloaders.Close 2020-10-06 16:35:23 +01:00
writeback vfs cache: make logging consistent and remove some debug logging 2020-07-06 17:32:53 +01:00
cache_test.go vfs: support synchronous cache space recovery upon ENOSPC 2020-08-25 21:12:06 +01:00
cache.go mount cmd: update systemd status with cache stats 2020-10-06 16:21:30 +01:00
item_test.go vfs: Add recovered items on cache reload to directory listings 2020-06-30 12:03:39 +01:00
item.go vfs: detect and recover from a file being removed externally from the cache 2020-09-18 10:30:02 +01:00