mirror of
https://github.com/versity/scoutfs.git
synced 2026-01-09 13:23:14 +00:00
Clear lock invalidate_pending during destroy
Locks have a bunch of state that reflects concurrent processing. Testing that state determines when it's safe to free a lock because nothing is going on. During unmount we abruptly stop processing locks. Unmount will send a farewell to the server which will remove all the state associated with the client that's unmounting for all its locks, regardless of the state the locks were in. The client unmount path has to clean up the interupted lock state and free it, carefully avoiding assertions that would otherwise indicate that we're freeing used locks. The move to async lock invalidation forgot to clean up the invalidation state. Previously a synchronous work function would set and clear invalidate_pending while it was running. Once we finished waiting for it invalidate_pending would be clear. The move to async invalidation work meant that we can still have invalidate_pending with no work executing. Lock destruction removed locks from the invalidation list but forgot to clear the invalidate_pending flag. This triggered assertions during unmount that were otherwise harmless. There was other use of the lock, we just forgot to clean up the lock state. Signed-off-by: Zach Brown <zab@versity.com>
This commit is contained in:
@@ -1714,8 +1714,10 @@ void scoutfs_lock_destroy(struct super_block *sb)
|
||||
__lock_del_lru(linfo, lock);
|
||||
if (!list_empty(&lock->grant_head))
|
||||
list_del_init(&lock->grant_head);
|
||||
if (!list_empty(&lock->inv_head))
|
||||
if (!list_empty(&lock->inv_head)) {
|
||||
list_del_init(&lock->inv_head);
|
||||
lock->invalidate_pending = 0;
|
||||
}
|
||||
if (!list_empty(&lock->shrink_head))
|
||||
list_del_init(&lock->shrink_head);
|
||||
lock_remove(linfo, lock);
|
||||
|
||||
Reference in New Issue
Block a user