From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org, piaojun@huawei.com, mark@fasheh.com,
junxiao.bi@oracle.com, joseph.qi@linux.alibaba.com,
jlbec@evilplan.org, ghe@suse.com, gechangwei@live.cn,
ocfs2-devel@oss.oracle.com, akpm@linux-foundation.org
Subject: [merged mm-nonmm-stable] ocfs2-dlmfs-not-clear-user_lock_attached-when-destroy-lock.patch removed from -mm tree
Date: Wed, 25 May 2022 13:06:55 -0700 [thread overview]
Message-ID: <20220525200656.96B36C385B8@smtp.kernel.org> (raw)
The quilt patch titled
Subject: ocfs2: dlmfs: don't clear USER_LOCK_ATTACHED when destroying lock
has been removed from the -mm tree. Its filename was
ocfs2-dlmfs-not-clear-user_lock_attached-when-destroy-lock.patch
This patch was dropped because it was merged into the mm-nonmm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Junxiao Bi <ocfs2-devel@oss.oracle.com>
Subject: ocfs2: dlmfs: don't clear USER_LOCK_ATTACHED when destroying lock
Date: Wed, 18 May 2022 16:52:23 -0700
The following function is the only place that checks USER_LOCK_ATTACHED.
This flag is set when lock request is granted through user_ast() and only
the following function will clear it.
Checking of this flag here is to make sure ocfs2_dlm_unlock is not issued
if this lock is never granted. For example, lock file is created and then
get removed, open file never happens.
Clearing the flag here is not necessary because this is the only function
that checks it, if another flow is executing user_dlm_destroy_lock(), it
will bail out at the beginning because of USER_LOCK_IN_TEARDOWN and never
check USER_LOCK_ATTACHED. Drop the clear, so we don't need take care of
it for the following error handling patch.
int user_dlm_destroy_lock(struct user_lock_res *lockres)
{
...
status = 0;
if (!(lockres->l_flags & USER_LOCK_ATTACHED)) {
spin_unlock(&lockres->l_lock);
goto bail;
}
lockres->l_flags &= ~USER_LOCK_ATTACHED;
lockres->l_flags |= USER_LOCK_BUSY;
spin_unlock(&lockres->l_lock);
status = ocfs2_dlm_unlock(conn, &lockres->l_lksb, DLM_LKF_VALBLK);
if (status) {
user_log_dlm_error("ocfs2_dlm_unlock", status, lockres);
goto bail;
}
...
}
V1 discussion with Joseph:
https://lore.kernel.org/all/7b620c53-0c45-da2c-829e-26195cbe7d4e@linux.alibaba.com/T/
Link: https://lkml.kernel.org/r/20220518235224.87100-1-junxiao.bi@oracle.com
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/ocfs2/dlmfs/userdlm.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/ocfs2/dlmfs/userdlm.c~ocfs2-dlmfs-not-clear-user_lock_attached-when-destroy-lock
+++ a/fs/ocfs2/dlmfs/userdlm.c
@@ -619,7 +619,6 @@ int user_dlm_destroy_lock(struct user_lo
goto bail;
}
- lockres->l_flags &= ~USER_LOCK_ATTACHED;
lockres->l_flags |= USER_LOCK_BUSY;
spin_unlock(&lockres->l_lock);
_
Patches currently in -mm which might be from ocfs2-devel@oss.oracle.com are
ocfs2-dlmfs-fix-error-handling-of-user_dlm_destroy_lock.patch
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton via Ocfs2-devel <ocfs2-devel@oss.oracle.com>
To: mm-commits@vger.kernel.org, piaojun@huawei.com, mark@fasheh.com,
junxiao.bi@oracle.com, joseph.qi@linux.alibaba.com,
jlbec@evilplan.org, ghe@suse.com, gechangwei@live.cn,
ocfs2-devel@oss.oracle.com, akpm@linux-foundation.org
Subject: [Ocfs2-devel] [merged mm-nonmm-stable] ocfs2-dlmfs-not-clear-user_lock_attached-when-destroy-lock.patch removed from -mm tree
Date: Wed, 25 May 2022 13:06:55 -0700 [thread overview]
Message-ID: <20220525200656.96B36C385B8@smtp.kernel.org> (raw)
The quilt patch titled
Subject: ocfs2: dlmfs: don't clear USER_LOCK_ATTACHED when destroying lock
has been removed from the -mm tree. Its filename was
ocfs2-dlmfs-not-clear-user_lock_attached-when-destroy-lock.patch
This patch was dropped because it was merged into the mm-nonmm-stable branch
of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
------------------------------------------------------
From: Junxiao Bi <ocfs2-devel@oss.oracle.com>
Subject: ocfs2: dlmfs: don't clear USER_LOCK_ATTACHED when destroying lock
Date: Wed, 18 May 2022 16:52:23 -0700
The following function is the only place that checks USER_LOCK_ATTACHED.
This flag is set when lock request is granted through user_ast() and only
the following function will clear it.
Checking of this flag here is to make sure ocfs2_dlm_unlock is not issued
if this lock is never granted. For example, lock file is created and then
get removed, open file never happens.
Clearing the flag here is not necessary because this is the only function
that checks it, if another flow is executing user_dlm_destroy_lock(), it
will bail out at the beginning because of USER_LOCK_IN_TEARDOWN and never
check USER_LOCK_ATTACHED. Drop the clear, so we don't need take care of
it for the following error handling patch.
int user_dlm_destroy_lock(struct user_lock_res *lockres)
{
...
status = 0;
if (!(lockres->l_flags & USER_LOCK_ATTACHED)) {
spin_unlock(&lockres->l_lock);
goto bail;
}
lockres->l_flags &= ~USER_LOCK_ATTACHED;
lockres->l_flags |= USER_LOCK_BUSY;
spin_unlock(&lockres->l_lock);
status = ocfs2_dlm_unlock(conn, &lockres->l_lksb, DLM_LKF_VALBLK);
if (status) {
user_log_dlm_error("ocfs2_dlm_unlock", status, lockres);
goto bail;
}
...
}
V1 discussion with Joseph:
https://lore.kernel.org/all/7b620c53-0c45-da2c-829e-26195cbe7d4e@linux.alibaba.com/T/
Link: https://lkml.kernel.org/r/20220518235224.87100-1-junxiao.bi@oracle.com
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
fs/ocfs2/dlmfs/userdlm.c | 1 -
1 file changed, 1 deletion(-)
--- a/fs/ocfs2/dlmfs/userdlm.c~ocfs2-dlmfs-not-clear-user_lock_attached-when-destroy-lock
+++ a/fs/ocfs2/dlmfs/userdlm.c
@@ -619,7 +619,6 @@ int user_dlm_destroy_lock(struct user_lo
goto bail;
}
- lockres->l_flags &= ~USER_LOCK_ATTACHED;
lockres->l_flags |= USER_LOCK_BUSY;
spin_unlock(&lockres->l_lock);
_
Patches currently in -mm which might be from ocfs2-devel@oss.oracle.com are
ocfs2-dlmfs-fix-error-handling-of-user_dlm_destroy_lock.patch
_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
next reply other threads:[~2022-05-25 20:07 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-25 20:06 Andrew Morton [this message]
2022-05-25 20:06 ` [Ocfs2-devel] [merged mm-nonmm-stable] ocfs2-dlmfs-not-clear-user_lock_attached-when-destroy-lock.patch removed from -mm tree Andrew Morton via Ocfs2-devel
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=20220525200656.96B36C385B8@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=gechangwei@live.cn \
--cc=ghe@suse.com \
--cc=jlbec@evilplan.org \
--cc=joseph.qi@linux.alibaba.com \
--cc=junxiao.bi@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark@fasheh.com \
--cc=mm-commits@vger.kernel.org \
--cc=ocfs2-devel@oss.oracle.com \
--cc=piaojun@huawei.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.