So far, glocks were instantiated inside of do_promote() as part of the glock state engine logic. This code can be moved outside the state engine, which simplifies things significantly. We no longer need to release and re-acquire the glock spin lock in do_promote(), so the glock holder we're trying to instantiate can no longer go away under us by accident. (Function do_promote() isn't always run in process context.)
To facilitate that, first fix and clean up gfs2_glock_async_wait() to take advantage of the fact that canceling glock operations now works properly. With the above changes in place, split off a new go_held() glock operation for actions to be performed whenever a new holder for a glock is granted: some of the actions carried out by inode_go_instantiate() are meant to be carried out repeatedly, so move those over to the new inode_go_held() handler. Finally, Bob has found the remaining bug in the glock holder auto-demotion feature we've disabled for 5.18; fix that and re-enable the feature. Thanks, Andreas Andreas Gruenbacher (8): gfs2: Fix up gfs2_glock_async_wait gfs2: Instantiate glocks ouside of glock state engine gfs2: Revert 'Fix "truncate in progress" hang' gfs2: Add new go_held glock operation gfs2: Make go_instantiate take a glock gfs2: Use better variable name gfs2: List traversal in do_promote is safe Revert "gfs2: Stop using glock holder auto-demotion for now" Bob Peterson (1): gfs2: do_promote glock holder stealing fix fs/gfs2/file.c | 46 +++++++---- fs/gfs2/glock.c | 187 +++++++++++++++++-------------------------- fs/gfs2/glock.h | 2 +- fs/gfs2/glops.c | 31 ++++--- fs/gfs2/incore.h | 6 +- fs/gfs2/main.c | 1 - fs/gfs2/ops_fstype.c | 2 - fs/gfs2/quota.c | 28 +------ fs/gfs2/rgrp.c | 3 +- fs/gfs2/rgrp.h | 2 +- fs/gfs2/super.c | 2 +- 11 files changed, 126 insertions(+), 184 deletions(-) -- 2.35.1
