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
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
19 matches
Mail list logo
