On 17/1/12 19:24, Eric Ren wrote:
Hi Joseph,
On 01/09/2017 10:13 AM, Eric Ren wrote:
So you are trying to fix it by making phase3 finish without really
doing
Phase3 can go ahead because this node is already under protection
of cluster lock.
You said it was blocked...
Oh, sorry, I meant phase3 can go ahead if this patch set is applied;-)
"Another hand, the recursive cluster lock (the second one) will be
blocked in
__ocfs2_cluster_lock() because of OCFS2_LOCK_BLOCKED."
__ocfs2_cluster_lock, then Process B can continue either.
Let us bear in mind that phase1 and phase3 are in the same context
and
executed in order. That's why I think there is no need to check if
locked
by myself in phase1.
Sorry, I still cannot see it. Without keeping track of the first
cluster lock, how can we
know if
we are under a context that has already been in the protecting of
cluster lock? How can we
handle
the recursive locking (the second cluster lock) if we don't have this
information?
If phase1 finds it is already locked by myself, that means the holder
is left by last operation without dec holder. That's why I think
it is a bug
instead of a recursive lock case.
I think I got your point here. Do you mean that we should just add
the lock holder at the
first locking position
without checking before that? Unfortunately, it's tricky here to know
exactly which ocfs2
routine will be the first vfs
entry point, such as ocfs2_get_acl() which can be both the first vfs
entry point and the
second vfs entry point after
ocfs2_permission(), right?
It will be a coding bug if the problem you concern about happens. I
think we don't need to
worry about this much because
the code logic here is quite simple;-)
Ping...
Did I clear your doubts by the last email? I really want to get your
point, if not.
If there's any problem, I will fix them in the next version;-)
Yes, but I still worry about the code bug case will be hidden behind
recursive lock...
Anyway, It depends on others...
Thanks,
Joseph
Thanks,
Eric
Thanks for your patience!
Eric
D
