From ef9be95f5c889c482ad2b3e33f3b89163561d2f4 Mon Sep 17 00:00:00 2001 From: Auke Kok Date: Wed, 1 Jul 2026 10:11:09 -0700 Subject: [PATCH] Fix refresh_gen reading wrong lock for mode 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 --- kmod/src/lock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kmod/src/lock.c b/kmod/src/lock.c index f3b21345..3339364b 100644 --- a/kmod/src/lock.c +++ b/kmod/src/lock.c @@ -627,7 +627,7 @@ int scoutfs_lock_grant_response(struct super_block *sb, bug_on_inconsistent_grant_cache(sb, lock, nl->old_mode, nl->new_mode); - if (!lock_mode_can_read(nl->old_mode) && lock_mode_can_read(nl->new_mode)) + if (!lock_mode_can_read(lock->mode) && lock_mode_can_read(nl->new_mode)) lock->refresh_gen = atomic64_inc_return(&linfo->next_refresh_gen); lock->request_pending = 0;