From: Alexander Aring <aahringo@redhat.com>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] [PATCH v6.1-rc1 03/18] fs: dlm: remove send repeat remove handling
Date: Thu, 27 Oct 2022 16:45:13 -0400 [thread overview]
Message-ID: <20221027204528.1119036-3-aahringo@redhat.com> (raw)
In-Reply-To: <20221027204528.1119036-1-aahringo@redhat.com>
This patch removes the send repeat remove handling. This handling is
there to repeatingly DLM_MSG_REMOVE messages in cases the dlm stack
thinks it was not received at the first time. In cases of message drops
this functionality is necessary, but since the DLM midcomms layer
guarantees there are no messages drops between cluster nodes this
feature became not strict necessary anymore. Due message
delays/processing it could be that two send_repeat_remove() are sent out
while the other should be still on it's way. We remove the repeat remove
handling because we are sure that the message cannot be dropped due
communication errors.
Signed-off-by: Alexander Aring <aahringo@redhat.com>
---
fs/dlm/lock.c | 74 ---------------------------------------------------
1 file changed, 74 deletions(-)
diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c
index 94a72ede5764..b246d71b5e17 100644
--- a/fs/dlm/lock.c
+++ b/fs/dlm/lock.c
@@ -4044,66 +4044,6 @@ static int validate_message(struct dlm_lkb *lkb, struct dlm_message *ms)
return error;
}
-static void send_repeat_remove(struct dlm_ls *ls, char *ms_name, int len)
-{
- char name[DLM_RESNAME_MAXLEN + 1];
- struct dlm_message *ms;
- struct dlm_mhandle *mh;
- struct dlm_rsb *r;
- uint32_t hash, b;
- int rv, dir_nodeid;
-
- memset(name, 0, sizeof(name));
- memcpy(name, ms_name, len);
-
- hash = jhash(name, len, 0);
- b = hash & (ls->ls_rsbtbl_size - 1);
-
- dir_nodeid = dlm_hash2nodeid(ls, hash);
-
- log_error(ls, "send_repeat_remove dir %d %s", dir_nodeid, name);
-
- spin_lock(&ls->ls_rsbtbl[b].lock);
- rv = dlm_search_rsb_tree(&ls->ls_rsbtbl[b].keep, name, len, &r);
- if (!rv) {
- spin_unlock(&ls->ls_rsbtbl[b].lock);
- log_error(ls, "repeat_remove on keep %s", name);
- return;
- }
-
- rv = dlm_search_rsb_tree(&ls->ls_rsbtbl[b].toss, name, len, &r);
- if (!rv) {
- spin_unlock(&ls->ls_rsbtbl[b].lock);
- log_error(ls, "repeat_remove on toss %s", name);
- return;
- }
-
- /* use ls->remove_name2 to avoid conflict with shrink? */
-
- spin_lock(&ls->ls_remove_spin);
- ls->ls_remove_len = len;
- memcpy(ls->ls_remove_name, name, DLM_RESNAME_MAXLEN);
- spin_unlock(&ls->ls_remove_spin);
- spin_unlock(&ls->ls_rsbtbl[b].lock);
-
- rv = _create_message(ls, sizeof(struct dlm_message) + len,
- dir_nodeid, DLM_MSG_REMOVE, &ms, &mh);
- if (rv)
- goto out;
-
- memcpy(ms->m_extra, name, len);
- ms->m_hash = cpu_to_le32(hash);
-
- send_message(mh, ms);
-
-out:
- spin_lock(&ls->ls_remove_spin);
- ls->ls_remove_len = 0;
- memset(ls->ls_remove_name, 0, DLM_RESNAME_MAXLEN);
- spin_unlock(&ls->ls_remove_spin);
- wake_up(&ls->ls_remove_wait);
-}
-
static int receive_request(struct dlm_ls *ls, struct dlm_message *ms)
{
struct dlm_lkb *lkb;
@@ -4173,25 +4113,11 @@ static int receive_request(struct dlm_ls *ls, struct dlm_message *ms)
ENOTBLK request failures when the lookup reply designating us
as master is delayed. */
- /* We could repeatedly return -EBADR here if our send_remove() is
- delayed in being sent/arriving/being processed on the dir node.
- Another node would repeatedly lookup up the master, and the dir
- node would continue returning our nodeid until our send_remove
- took effect.
-
- We send another remove message in case our previous send_remove
- was lost/ignored/missed somehow. */
-
if (error != -ENOTBLK) {
log_limit(ls, "receive_request %x from %d %d",
le32_to_cpu(ms->m_lkid), from_nodeid, error);
}
- if (namelen && error == -EBADR) {
- send_repeat_remove(ls, ms->m_extra, namelen);
- msleep(1000);
- }
-
setup_stub_lkb(ls, ms);
send_request_reply(&ls->ls_stub_rsb, &ls->ls_stub_lkb, error);
return error;
--
2.31.1
next prev parent reply other threads:[~2022-10-27 20:45 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-27 20:45 [Cluster-devel] [PATCH v6.1-rc1 01/18] fs: dlm: fix sock release if listen fails Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 02/18] fs: dlm: retry accept() until -EAGAIN or error returns Alexander Aring
2022-10-27 20:45 ` Alexander Aring [this message]
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 04/18] fs: dlm: use packet in dlm_mhandle Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 05/18] fd: dlm: trace send/recv of dlm message and rcom Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 06/18] fs: dlm: let dlm_add_cb queue work after resume only Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 07/18] fs: dlm: use list_first_entry marco Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 08/18] fs: dlm: convert ls_cb_mutex mutex to spinlock Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 09/18] fs: dlm: use spin lock instead of mutex Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 10/18] fs: dlm: move last cast bast time to function call Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 11/18] fs: dlm: use a non-static queue for callbacks Alexander Aring
2022-10-28 21:17 ` Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 12/18] fs: dlm: allow different allocation context per _create_message Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 13/18] fs: dlm: remove ls_remove_wait waitqueue Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 14/18] fs: dlm: relax sending to allow receiving Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 15/18] fs: dlm: catch dlm_add_member() error Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 16/18] fs: dlm: fix log of lowcomms vs midcomms Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 17/18] fs: dlm: use WARN_ON_ONCE() instead of WARN_ON() Alexander Aring
2022-10-27 20:45 ` [Cluster-devel] [PATCH v6.1-rc1 18/18] fs: dlm: rework lowcomms handling Alexander Aring
2022-10-28 21:25 ` Alexander Aring
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20221027204528.1119036-3-aahringo@redhat.com \
--to=aahringo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).