mirrors/scoutfs
1
0
Fork 0
mirror of https://github.com/versity/scoutfs.git synced 2026-07-19 06:22:24 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fix refresh_gen reading wrong lock for mode

Browse Source 
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>
This commit is contained in:
Auke Kok
2026-07-01 10:11:09 -07:00
parent fab589700e
commit ef9be95f5c
1 changed files with 1 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
kmod/src/lock.c
+1 -1
View File
@@ -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;