[Ocfs2-devel] [PATCH] remove lockres from purge list when we are getting it for creating lock

[Srinivas Eeda <srinivas.eeda@oracle.com>]

>>> +		spin_unlock(&tmpres->spinlock);
>>> +		spin_unlock(&dlm->spinlock);
>> lockres could still get added to purgelist at this point and we
>> could still have the same problem? I think, here we need some
>> mechanism that marks the lockres is in use that would protect it
>> from adding to the purgelist?
> Seems there shouldn't be the possibility that the lockres was moved to purge
> list again.
I think you are right about that once removed from the purge list it 
will not be put back again on the purgelist in this case :)

I still think that there is a hole here. Is it possible that the 
spinlocks are released here and right then dlm_thread was walking 
through dirty list and then it could put this on purge list for the 
first time?

If it's already on purgelist, then we seem to be safe by removing it. 
But what is preventing the lockres getting onto to purge list right at 
this point. locks are added to lockres a little later but till then it 
is not safe?(I think).

>   We are in the case of a "create lock", there should not be any
> outstanding convert/unlock request in progress concurrently. If there is one,
> the there must be lock(s) attached to the lockres. But if there are locks
> attached, the lockres can't be purged. Also for concurrent "create lock", there
> is no problem either because there must be a lock attached to the lockres.
>
> I think your patch works too. But changing
> DLM_LOCK_RES_IN_USE
> to
> DLM_LOCK_RES_CREATING_LOCK
> can help understand better.
I am ok with the name :). The thing we should do here is once we found a 
lockres and moving ahead with create lock request, we should be sure 
it's protected before releasing the spinlocks.
> I also thought about inflight_locks, but so far I failed to find correct
> places to drop it.
>
> thanks,
> wengang.
>>>   		if (res)
>>>   			dlm_lockres_put(res);
>>>   		res = tmpres;