On 12/14/2015 01:39 PM, Gang He wrote:
> Hello Junxiao,
>
> From the initial description, the second lock_XYZ(PR) should be blocked,
> since DLM have a fair queue mechanism, otherwise, it looks to bring a write
> lock starvation.
Should be blocked? No, that is a deadlock. I don't think this rec
On 12/09/2015 06:19 PM, jiangyiwen wrote:
> commit f3f854648de6("ocfs2_dlm: Ensure correct ordering of set/clear
> refmap bit on lockres") still exists a race which can't ensure the
> ordering is exactly correct.
>
> Node1 Node2Node3
> umount, migrate
> lockres to
Hello Junxiao,
>From the initial description, the second lock_XYZ(PR) should be blocked, since
>DLM have a fair queue mechanism, otherwise, it looks to bring a write lock
>starvation.
Second, this issue can be reproduced in old Linux kernels (e.g. 3.16.7-24)?
there should not be any regression
Hi Joseph,
On 12/10/2015 06:36 PM, Joseph Qi wrote:
> Hi Ryan,
>
> On 2015/12/10 16:48, Ryan Ding wrote:
>> Hi Joseph,
>>
>> Thanks for your comments, please see my reply:
>>
>> On 12/10/2015 03:54 PM, Joseph Qi wrote:
>>> Hi Ryan,
>>>
>>> On 2015/10/12 14:34, Ryan Ding wrote:
Hi Joseph,
On 12/11/2015 11:09 AM, Xue jiufei wrote:
> We found a race between purge and migration when doing code review. Node
> A put lockres to purgelist before receiving the migrate message from node
> B which is the master. Node A call dlm_mig_lockres_handler to handle
> this message.
>
> dlm_mig_lockr
The following locking order can cause a deadlock.
Process A on Node X: Process B on Node Y:
lock_XYZ(PR)
lock_XYZ(EX)
lock_XYZ(PR) >>> blocked forever by OCFS2_LOCK_BLOCKED.
Use ocfs2-test multiple reflink test can reproduce this on v4.3 kernel,
