summaryrefslogtreecommitdiffstats
path: root/fs/dlm/user.c
diff options
context:
space:
mode:
authorAlexander Aring <aahringo@redhat.com>2023-05-29 23:44:35 +0200
committerDavid Teigland <teigland@redhat.com>2023-06-14 17:17:33 +0200
commit5ce9ef30f226c43aa711a4807077447251efa0c6 (patch)
treee61dc2d78a48d73138d49e37f3cdda63605752fb /fs/dlm/user.c
parentfs: dlm: cleanup STOP_IO bitflag set when stop io (diff)
downloadlinux-5ce9ef30f226c43aa711a4807077447251efa0c6.tar.xz
linux-5ce9ef30f226c43aa711a4807077447251efa0c6.zip
fs: dlm: move dlm_purge_lkb_callbacks to user module
This patch moves the dlm_purge_lkb_callbacks() function from ast to user dlm module as it is only a function being used by dlm user implementation. I got be hinted to hold specific locks regarding the callback handling for dlm_purge_lkb_callbacks() but it was false positive. It is confusing because ast dlm implementation uses a different locking behaviour as user locks uses as DLM handles kernel and user dlm locks differently. To avoid the confusing we move this function to dlm user implementation. Signed-off-by: Alexander Aring <aahringo@redhat.com> Signed-off-by: David Teigland <teigland@redhat.com>
Diffstat (limited to 'fs/dlm/user.c')
-rw-r--r--fs/dlm/user.c18
1 files changed, 18 insertions, 0 deletions
diff --git a/fs/dlm/user.c b/fs/dlm/user.c
index d9c09fc0aba1..695e691b38b3 100644
--- a/fs/dlm/user.c
+++ b/fs/dlm/user.c
@@ -145,6 +145,24 @@ static void compat_output(struct dlm_lock_result *res,
}
#endif
+/* should held proc->asts_spin lock */
+void dlm_purge_lkb_callbacks(struct dlm_lkb *lkb)
+{
+ struct dlm_callback *cb, *safe;
+
+ list_for_each_entry_safe(cb, safe, &lkb->lkb_callbacks, list) {
+ list_del(&cb->list);
+ kref_put(&cb->ref, dlm_release_callback);
+ }
+
+ clear_bit(DLM_IFL_CB_PENDING_BIT, &lkb->lkb_iflags);
+
+ /* invalidate */
+ dlm_callback_set_last_ptr(&lkb->lkb_last_cast, NULL);
+ dlm_callback_set_last_ptr(&lkb->lkb_last_cb, NULL);
+ lkb->lkb_last_bast_mode = -1;
+}
+
/* Figure out if this lock is at the end of its life and no longer
available for the application to use. The lkb still exists until
the final ast is read. A lock becomes EOL in three situations: