Hi!
On 01/17/2017 04:43 PM, Joseph Qi wrote:
> On 17/1/17 15:55, Eric Ren wrote:
>> Hi!
>>
>> On 01/17/2017 03:39 PM, Joseph Qi wrote:
>>>
>>> On 17/1/17 14:30, Eric Ren wrote:
We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a
On 17/1/17 15:55, Eric Ren wrote:
> Hi!
>
> On 01/17/2017 03:39 PM, Joseph Qi wrote:
>>
>> On 17/1/17 14:30, Eric Ren wrote:
>>> We are in the situation that we have to avoid recursive cluster
>>> locking,
>>> but there is no way to check if a cluster lock has been taken by a
>>> precess already.
We are in the situation that we have to avoid recursive cluster locking,
but there is no way to check if a cluster lock has been taken by a
precess already.
Mostly, we can avoid recursive locking by writing code carefully.
However, we found that it's very hard to handle the routines that
are
Three loops can be optimized into one and its sub loops, so as small code can
do the same work.
From 8a1e682503f4e5a5299fe8316cbf559f9b9701f1 Mon Sep 17 00:00:00 2001
From: Guozhonghua
Date: Fri, 13 Jan 2017 11:27:32 +0800
Subject: [PATCH] Optimization of code while free
Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
results in a deadlock, as the author "Tariq Saeed" realized shortly
after the patch was merged. The discussion happened here
(https://oss.oracle.com/pipermail/ocfs2-devel/2015-September/011085.html).
The reason why taking
Hi Andrew,
This patch set version has got reviewed by Joseph and Junxiao Bi. I
think it's good to queued up now.
Thanks for all of you!
Eric
This is a formal patch set v2 to solve the deadlock issue on which I
previously started a RFC (draft patch), and the discussion happened here: