On 01/16/2017 11:13 AM, Junxiao Bi wrote:
On 01/16/2017 11:06 AM, Eric Ren wrote:
Hi Junxiao,
On 01/16/2017 10:46 AM, Junxiao Bi wrote:
If had_lock==true, it is a bug? I think we should BUG_ON for it, that
can help us catch bug at the first time.
Good idea! But I'm not sure if "ocfs2_setattr"
On 01/16/2017 11:06 AM, Eric Ren wrote:
> Hi Junxiao,
>
> On 01/16/2017 10:46 AM, Junxiao Bi wrote:
If had_lock==true, it is a bug? I think we should BUG_ON for it, that
can help us catch bug at the first time.
>>> Good idea! But I'm not sure if "ocfs2_setattr" is always the first one
>>
Hi Junxiao,
On 01/16/2017 10:46 AM, Junxiao Bi wrote:
If had_lock==true, it is a bug? I think we should BUG_ON for it, that
can help us catch bug at the first time.
Good idea! But I'm not sure if "ocfs2_setattr" is always the first one
who takes the cluster lock.
It's harder for me to name all
On 01/13/2017 02:19 PM, Eric Ren wrote:
> Hi!
>
> On 01/13/2017 12:22 PM, Junxiao Bi wrote:
>> On 01/05/2017 11:31 PM, Eric Ren wrote:
>>> Commit 743b5f1434f5 ("ocfs2: take inode lock in
>>> ocfs2_iop_set/get_acl()")
>>> results in a deadlock, as the author "Tariq Saeed" realized shortly
>>> after
Hi!
On 01/13/2017 12:22 PM, Junxiao Bi wrote:
On 01/05/2017 11:31 PM, Eric Ren wrote:
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://o
On 01/05/2017 11:31 PM, Eric Ren wrote:
> 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-S
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 phas
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 i
Hi Fengguang,
On 01/06/2017 10:52 PM, kbuild test robot wrote:
Hi Eric,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0da
Hi,
On 01/09/2017 09:13 AM, Joseph Qi wrote:
...
The issue case you are trying to fix is:
Process A
take inode lock (phase1)
...
<<< race window (phase2, Process B)
The deadlock only happens if process B is on a remote node and request EX lock.
Quote the patch[1/2]'s commit message:
A dea
On 17/1/6 19:56, Eric Ren wrote:
Hi!
On 01/06/2017 05:55 PM, Joseph Qi wrote:
On 17/1/6 17:13, Eric Ren wrote:
Hi,
Fixes them by adding the tracking logic (in the previous
patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
As described cases abo
Hi Eric,
[auto build test WARNING on linus/master]
[also build test WARNING on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Eric-Ren/fix-deadlock-caused-by-recursive-c
Hi Eric,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc2 next-20170106]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Eric-Ren/fix-deadlock-caused-by-recursive-clust
Hi!
On 01/06/2017 05:55 PM, Joseph Qi wrote:
On 17/1/6 17:13, Eric Ren wrote:
Hi,
Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
As described cases above, shall we just add the tracking l
On 17/1/6 17:13, Eric Ren wrote:
Hi,
Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
As described cases above, shall we just add the tracking logic
only for set/get_acl()?
The idea is to d
Hi,
Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
As described cases above, shall we just add the tracking logic only for
set/get_acl()?
The idea is to detect recursive locking on the ru
On 17/1/6 16:21, Eric Ren wrote:
On 01/06/2017 03:14 PM, Joseph Qi wrote:
On 17/1/6 14:56, Eric Ren wrote:
On 01/06/2017 02:09 PM, Joseph Qi wrote:
Hi Eric,
On 17/1/5 23:31, Eric Ren wrote:
Commit 743b5f1434f5 ("ocfs2: take inode lock in
ocfs2_iop_set/get_acl()")
results in a deadlock,
On 01/06/2017 03:14 PM, Joseph Qi wrote:
On 17/1/6 14:56, Eric Ren wrote:
On 01/06/2017 02:09 PM, Joseph Qi wrote:
Hi Eric,
On 17/1/5 23:31, Eric Ren wrote:
Commit 743b5f1434f5 ("ocfs2: take inode lock in ocfs2_iop_set/get_acl()")
results in a deadlock, as the author "Tariq Saeed" realized
On 17/1/6 14:56, Eric Ren wrote:
On 01/06/2017 02:09 PM, Joseph Qi wrote:
Hi Eric,
On 17/1/5 23:31, Eric Ren wrote:
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
On 01/06/2017 02:09 PM, Joseph Qi wrote:
Hi Eric,
On 17/1/5 23:31, Eric Ren wrote:
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
Hi Eric,
On 17/1/5 23:31, Eric Ren wrote:
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-Sep
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 cl
22 matches
Mail list logo
