mirror of
https://github.com/versity/scoutfs.git
synced 2026-07-19 06:22:24 +00:00
Auke Kok
ef9be95f5c
This function determines if the local inode is cached under a different mode in the client local state. On receiving an updated mode it should therefore inspect it's own lock mode and not the mode passed by the server, which can have a different view after recovery. This was caught twice in CI by `BUG_ON(atomic64_read(&si->last_refreshed) > refresh_gen) in scoutfs_inode_refresh` in scoutfs_inode_refresh() during the lock-recover-invalidate test - our most flakey CI test by a mile. Pulling the core revealed the lock was mode=WRITE but refresh_gen=0 with invalidate_pending=1, which means it should have had refresh_gen assigned on the null to write transition. This happens because it's only assigned if the server-supplied lock changes, because it doesn't look at the client's view of the state: `!can_read(nl->old_mode) && can_read(nl->new_mode)` Exactly the thing that can go wrong after a server fence/recovery, as exposed by this CI test. Signed-off-by: Auke Kok <auke.kok@versity.com>