mirror of
https://github.com/versity/scoutfs.git
synced 2026-04-25 15:50:29 +00:00
65ac42831f
The locking protocol only allows one outstanding invalidation request for a lock at a time. The client invalidation state is a bit hairy and involves removing the lock from the invalidation list while it is being processed which includes sending the response. This means that another request can arrive while the lock is not on the invalidation list. We have fields in the lock to record another incoming request which puts the lock back on the list. But the invalidation work wasn't always queued again in this case. It *looks* like the incoming request path would queue the work, but by definition the lock isn't on the invalidation list during this race. If it's the only lock in play then the invalidation list will be empty and the work won't be queued. The lock can get stuck with a pending invalidation if nothing else kicks the invaliation worker. We saw this in testing when the root inode lock group missed the wakeup. The fix is to have the work requeue itself after putting the lock back on the invalidation list when it notices that another request came in. Signed-off-by: Zach Brown <zab@versity.com>