re_imc_3
Signed-off-by: Shanpei Chen <shanp...@linux.alibaba.com>
Signed-off-by: Eric Ren <renz...@linux.alibaba.com>
Reviewed-by: Kan Liang <kan.li...@linux.intel.com>
---
Changes since v1:
1. As Kan Liang suggested, use the same coding style as the existing
code, also better re
re_imc_3
Signed-off-by: Shanpei Chen
Signed-off-by: Eric Ren
Reviewed-by: Kan Liang
---
Changes since v1:
1. As Kan Liang suggested, use the same coding style as the existing
code, also better readability.
---
arch/x86/events/intel/uncore.c | 9 -
arch/x86/events/intel/uncore.h | 1 +
re_imc_3
Signed-off-by: Shanpei Chen <shanp...@linux.alibaba.com>
Signed-off-by: Eric Ren <renz...@linux.alibaba.com>
---
arch/x86/events/intel/uncore.c | 7 ++-
arch/x86/events/intel/uncore.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/
re_imc_3
Signed-off-by: Shanpei Chen
Signed-off-by: Eric Ren
---
arch/x86/events/intel/uncore.c | 7 ++-
arch/x86/events/intel/uncore.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index a7956fc..88d390e 1
Hi,
On 12/27/2017 05:29 PM, Gang He wrote:
If we can't get inode lock immediately in the function
ocfs2_inode_lock_with_page() when reading a page, we should not
return directly here, since this will lead to a softlockup problem.
The method is to get a blocking lock and immediately unlock
Hi,
On 12/27/2017 05:29 PM, Gang He wrote:
If we can't get inode lock immediately in the function
ocfs2_inode_lock_with_page() when reading a page, we should not
return directly here, since this will lead to a softlockup problem.
The method is to get a blocking lock and immediately unlock
f it's possible to make them all into stable.
Thanks,
Eric
On 17/6/22 09:47, Eric Ren wrote:
Another deadlock path caused by recursive locking is reported.
This kind of issue was introduced since commit 743b5f1434f5 ("ocfs2:
take inode lock in ocfs2_iop_set/get_acl()"). Two deadlock paths
have
using ocfs2_inode_{lock|unlock}_tracker, which is
exported by commit 439a36b8ef38 ("ocfs2/dlmglue: prepare tracking
logic to avoid recursive cluster lock").
Changes since v1:
- Revised git commit description style in commit log.
Reported-by: Thomas Voegtle
Tested-by: Thomas Voegtle
Sign
lock}_tracker, which is
exported by commit 439a36b8ef38 ("ocfs2/dlmglue: prepare tracking
logic to avoid recursive cluster lock").
Changes since v1:
- Revised git commit description style in commit log.
Reported-by: Thomas Voegtle <t...@lio96.de>
Tested-by: Thomas Voegtle <t.
lock}_tracker, which is
exported by commit 439a36b8ef38 ("ocfs2/dlmglue: prepare tracking
logic to avoid recursive cluster lock").
Changes since v1:
- Revised git commit description style in commit log.
Reported-by: Thomas Voegtle
Tested-by: Thomas Voegtle
Signed-off-by: Eric Ren
---
fs
ion is not total safe,
base on the design of stackglue, we need to get ocfs2_stack_lock lock
before using ocfs2_stack related data structures, and that
active_stack pointer can be NULL in case mount failure.
Signed-off-by: Gang He <g...@suse.com>
Looks good.
Reviewed-by: Eric Ren <z...@suse.com>
ion is not total safe,
base on the design of stackglue, we need to get ocfs2_stack_lock lock
before using ocfs2_stack related data structures, and that
active_stack pointer can be NULL in case mount failure.
Signed-off-by: Gang He
Looks good.
Reviewed-by: Eric Ren
Eric
---
fs/ocfs2/dlmglue.c | 2 +-
lock}_tracker, which is
exported by 439a36b8ef38 ("ocfs2/dlmglue: prepare tracking logic to
avoid recursive cluster lock").
Reported-by:Thomas Voegtle <t...@lio96.de>
Tested-by: Thomas Voegtle <t...@lio96.de>
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/oc
lock}_tracker, which is
exported by 439a36b8ef38 ("ocfs2/dlmglue: prepare tracking logic to
avoid recursive cluster lock").
Reported-by:Thomas Voegtle
Tested-by: Thomas Voegtle
Signed-off-by: Eric Ren
---
fs/ocfs2/dlmglue.c | 4
fs/ocfs2/xattr.c | 23 +-
t;).
after apply this patch, the error return value will not be NULL(zero).
Signed-off-by: Gang He <g...@suse.com>
Looks good to me.
Reviewed-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ocfs2/inode.c b/
t;).
after apply this patch, the error return value will not be NULL(zero).
Signed-off-by: Gang He
Looks good to me.
Reviewed-by: Eric Ren
---
fs/ocfs2/inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ocfs2/inode.c b/fs/ocfs2/inode.c
index 382401d..1a1e007 10064
t ocfs2_setattr() and ocfs2_permission() to
catch exceptional cases, suggested by: Junxiao Bi.
Changes since v2:
- Use new wrappers of tracking logic code, suggested by: Junxiao Bi.
Signed-off-by: Eric Ren <z...@suse.com>
Reviewed-by: Junxiao Bi <junxiao...@oracle.
ses, suggested by: Junxiao Bi.
Changes since v2:
- Use new wrappers of tracking logic code, suggested by: Junxiao Bi.
Signed-off-by: Eric Ren
Reviewed-by: Junxiao Bi
Reviewed-by: Joseph Qi
---
fs/ocfs2/acl.c | 29 +
fs/ocfs2/file.c | 58 +++
anb.auug.org.au>.
Changes since v2:
- Use new wrappers of tracking logic code, suggested by: Junxiao Bi.
Change since v3:
- Fixes redundant space, spotted by: Joseph Qi.
Your comments and feedbacks are always welcomed.
Eric Ren (2):
ocfs2/dlmglue: prepare tracking logic to avoid recursive cl
ing into functions,
ocfs2_inode_lock_tracker() and ocfs2_inode_unlock_tracker(),
suggested by: Junxiao Bi.
Change since v3:
- Fixes redundant space, spotted by: Joseph Qi.
[s...@canb.auug.org.au remove some inlines]
Signed-off-by: Eric Ren <z...@suse.com>
Reviewed-by: Junxiao Bi <junxiao...@oracle.com&g
ested by: Junxiao Bi.
Change since v3:
- Fixes redundant space, spotted by: Joseph Qi.
Your comments and feedbacks are always welcomed.
Eric Ren (2):
ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
ocfs2: fix deadlock issue when taking inode lock at vfs entry points
fs/o
Change since v3:
- Fixes redundant space, spotted by: Joseph Qi.
[s...@canb.auug.org.au remove some inlines]
Signed-off-by: Eric Ren
Reviewed-by: Junxiao Bi
Reviewed-by: Joseph Qi
---
fs/ocfs2/dlmglue.c | 105 +++--
fs/ocfs2/dlmglue.h | 18 +
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 cluster lock has been
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 cluster lock has been
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.
Mostly, we can avoid recursive locking by writing code
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.
Mostly, we can avoid recursive locking by writing code
t ocfs2_setattr() and ocfs2_permission() to
catch exceptional cases, suggested by: Junxiao Bi.
Changes since v2:
- Use new wrappers of tracking logic code, suggested by: Junxiao Bi.
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/acl.c | 29 +
fs/ocfs2/file.c | 58 +
ing into functions,
ocfs2_inode_lock_tracker() and ocfs2_inode_unlock_tracker(),
suggested by: Junxiao Bi.
[s...@canb.auug.org.au remove some inlines]
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/dlmglue.c | 105 +++--
fs/ocfs2/dlmglue.h | 18 +
ion() to
catch exceptional cases, suggested by: Junxiao Bi.
- Do not inline functions whose bodies are not in scope, changed by:
Stephen Rothwell <s...@canb.auug.org.au>.
Changes since v2:
- Use new wrappers of tracking logic code, suggested by: Junxiao Bi.
Your comments and feedbacks are a
ses, suggested by: Junxiao Bi.
Changes since v2:
- Use new wrappers of tracking logic code, suggested by: Junxiao Bi.
Signed-off-by: Eric Ren
---
fs/ocfs2/acl.c | 29 +
fs/ocfs2/file.c | 58 -
2 files changed, 5
i.
[s...@canb.auug.org.au remove some inlines]
Signed-off-by: Eric Ren
---
fs/ocfs2/dlmglue.c | 105 +++--
fs/ocfs2/dlmglue.h | 18 +
fs/ocfs2/ocfs2.h | 1 +
3 files changed, 121 insertions(+), 3 deletions(-)
diff --git a/fs/ocfs2/dlmg
.
- Do not inline functions whose bodies are not in scope, changed by:
Stephen Rothwell .
Changes since v2:
- Use new wrappers of tracking logic code, suggested by: Junxiao Bi.
Your comments and feedbacks are always welcomed.
Eric Ren (2):
ocfs2/dlmglue: prepare tracking logic to avoid recursive
Hi!
On 01/16/2017 02:58 PM, Junxiao Bi wrote:
On 01/16/2017 02:42 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
Hi!
On 01/16/2017 02:58 PM, Junxiao Bi wrote:
On 01/16/2017 02:42 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
attr() and ocfs2_permission() to
catch exceptional cases, suggested by: Junxiao Bi <junxiao...@oracle.com>.
4. Do not inline functions whose bodies are not in scope, changed by:
Stephen Rothwell <s...@canb.auug.org.au>.
Your comments and feedbacks are always welcomed.
Eric Ren (2)
.
4. Do not inline functions whose bodies are not in scope, changed by:
Stephen Rothwell .
Your comments and feedbacks are always welcomed.
Eric Ren (2):
ocfs2/dlmglue: prepare tracking logic to avoid recursive cluster lock
ocfs2: fix deadlock issue when taking inode lock at vfs entry poi
ocfs2_holder" to a more meaningful name "ocfs2_lock_holder",
suggested by: Junxiao Bi <junxiao...@oracle.com>.
3. Do not inline functions whose bodies are not in scope, changed by:
Stephen Rothwell <s...@canb.auug.org.au>.
[s...@canb.auug.org.au remove some inlines]
Sig
. Add debugging output at ocfs2_setattr() and ocfs2_permission() to
catch exceptional cases, suggested by: Junxiao Bi <junxiao...@oracle.com>.
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/acl.c | 39 +
fs/ocfs2/file.c | 76 ++
ck_holder",
suggested by: Junxiao Bi .
3. Do not inline functions whose bodies are not in scope, changed by:
Stephen Rothwell .
[s...@canb.auug.org.au remove some inlines]
Signed-off-by: Eric Ren
---
fs/ocfs2/dlmglue.c | 48 +---
fs/ocfs2/dlmglue.h |
ate if the
process gets the cluster lock - suggested by: Joseph Qi
and Junxiao Bi .
2. Change "struct ocfs2_holder" to a more meaningful name "ocfs2_lock_holder",
suggested by: Junxiao Bi .
3. Add debugging output at ocfs2_setattr() and ocfs2_permission() to
catch exceptional
Hi Junxiao,
OK, good suggestion. Hrm, but in order to align with "ocfs2_inc_holders", I
think it's good to keep those function names as it is;-)
that name is also not very clear. Maybe you can make another patch to
clear it.
Maybe, the name completeness needs to compromise with the name
Hi Junxiao,
OK, good suggestion. Hrm, but in order to align with "ocfs2_inc_holders", I
think it's good to keep those function names as it is;-)
that name is also not very clear. Maybe you can make another patch to
clear it.
Maybe, the name completeness needs to compromise with the name
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_se
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_se
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
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 10:52 AM, Changwei Ge wrote:
Hi Joseph,
Do you think my last version of patch to fix umount hang after journal
flushing failure is OK?
If so, I 'd like to ask Andrew's help to merge this patch into his test
tree.
Thanks,
Br.
Changwei
The message above should not occur in a
On 01/13/2017 10:52 AM, Changwei Ge wrote:
Hi Joseph,
Do you think my last version of patch to fix umount hang after journal
flushing failure is OK?
If so, I 'd like to ask Andrew's help to merge this patch into his test
tree.
Thanks,
Br.
Changwei
The message above should not occur in a
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
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
Hi Junxiao!
On 01/13/2017 11:59 AM, Junxiao Bi wrote:
On 01/05/2017 11:31 PM, 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.
Mostly, we can avoid recursive locking
Hi Junxiao!
On 01/13/2017 11:59 AM, Junxiao Bi wrote:
On 01/05/2017 11:31 PM, 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.
Mostly, we can avoid recursive locking
Hi,
On 01/13/2017 11:42 AM, Stephen Rothwell wrote:
Hi Eric,
On Thu, 12 Jan 2017 13:06:01 +0800 Eric Ren <z...@suse.com> wrote:
Thanks for your report and the fix for it. The 0-day project has reported
several days ago,
but this patch set is still in discussion, so I am waiting for mor
Hi,
On 01/13/2017 11:42 AM, Stephen Rothwell wrote:
Hi Eric,
On Thu, 12 Jan 2017 13:06:01 +0800 Eric Ren wrote:
Thanks for your report and the fix for it. The 0-day project has reported
several days ago,
but this patch set is still in discussion, so I am waiting for more days to see
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
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
Hi Stephen,
Thanks for your report and the fix for it. The 0-day project has reported
several days ago,
but this patch set is still in discussion, so I am waiting for more days to see if other
developers
have any other questions.
I am confused that how to deal with your patch if I need to
Hi Stephen,
Thanks for your report and the fix for it. The 0-day project has reported
several days ago,
but this patch set is still in discussion, so I am waiting for more days to see if other
developers
have any other questions.
I am confused that how to deal with your patch if I need to
/0day-ci/linux/commits/Eric-Ren/fix-deadlock-caused-by-recursive-cluster-locking/20170106-200837
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin
/0day-ci/linux/commits/Eric-Ren/fix-deadlock-caused-by-recursive-cluster-locking/20170106-200837
config: ia64-allyesconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin
nks!
Eric
Thanks,
Joseph
Thanks,
Eric
Thanks,
Joseph
Thanks,
Eric
Thanks,
Joseph
Thanks for your review;-)
Eric
Thanks,
Joseph
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/acl.c | 39 ++-
fs/ocfs2/file.c | 44 +++
nks!
Eric
Thanks,
Joseph
Thanks,
Eric
Thanks,
Joseph
Thanks,
Eric
Thanks,
Joseph
Thanks for your review;-)
Eric
Thanks,
Joseph
Signed-off-by: Eric Ren
---
fs/ocfs2/acl.c | 39 ++-
fs/ocfs2/file.c | 44 ++-
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
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
o need to unlock in such case.
Thanks,
Eric
Thanks,
Joseph
Thanks,
Eric
Thanks,
Joseph
Thanks for your review;-)
Eric
Thanks,
Joseph
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/acl.c | 39 ++-
o need to unlock in such case.
Thanks,
Eric
Thanks,
Joseph
Thanks,
Eric
Thanks,
Joseph
Thanks for your review;-)
Eric
Thanks,
Joseph
Signed-off-by: Eric Ren
---
fs/ocfs2/acl.c | 39 ++-
fs/ocfs2/file.c | 44 ++
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 &q
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 &q
On 01/06/2017 03:24 PM, Joseph Qi wrote:
On 17/1/6 15:03, Eric Ren wrote:
On 01/06/2017 02:07 PM, Joseph Qi wrote:
Hi Eric,
On 17/1/5 23:31, 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
On 01/06/2017 03:24 PM, Joseph Qi wrote:
On 17/1/6 15:03, Eric Ren wrote:
On 01/06/2017 02:07 PM, Joseph Qi wrote:
Hi Eric,
On 17/1/5 23:31, 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
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
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
On 01/06/2017 02:07 PM, Joseph Qi wrote:
Hi Eric,
On 17/1/5 23:31, 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.
Mostly, we can avoid recursive locking by writing
On 01/06/2017 02:07 PM, Joseph Qi wrote:
Hi Eric,
On 17/1/5 23:31, 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.
Mostly, we can avoid recursive locking by writing
cfs2_iop_get_acl <=== take PR
ocfs2_iop_set_acl <=== take EX
Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/acl.c | 39
cfs2_iop_get_acl <=== take PR
ocfs2_iop_set_acl <=== take EX
Fixes them by adding the tracking logic (in the previous patch) for
these funcs above, ocfs2_permission(), ocfs2_iop_[set|get]_acl(),
ocfs2_setattr().
Signed-off-by: Eric Ren
---
fs/ocfs2/acl.c | 39 ++
et|set)_(acl|attr), and
the gfs2 code also do so.
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/dlmglue.c | 47 ---
fs/ocfs2/dlmglue.h | 18 ++
fs/ocfs2/ocfs2.h | 1 +
3 files changed, 63 insertions(+), 3 deletions(-)
dif
et|set)_(acl|attr), and
the gfs2 code also do so.
Signed-off-by: Eric Ren
---
fs/ocfs2/dlmglue.c | 47 ---
fs/ocfs2/dlmglue.h | 18 ++
fs/ocfs2/ocfs2.h | 1 +
3 files changed, 63 insertions(+), 3 deletions(-)
diff --git a/fs/ocfs2/dlm
messes up the dlmglue core, nor has a performance penalty on
the whole cluster locking system. Instead, it is only used in places where
such recursive cluster locking may happen.
Your comments and feedbacks are always welcomed.
Eric Ren (2):
ocfs2/dlmglue: prepare tracking logic to avoid
messes up the dlmglue core, nor has a performance penalty on
the whole cluster locking system. Instead, it is only used in places where
such recursive cluster locking may happen.
Your comments and feedbacks are always welcomed.
Eric Ren (2):
ocfs2/dlmglue: prepare tracking logic to avoid
one familiar with o2cb works out a patch for
o2cb in the future.
Does this sounds good to you?
Thanks,
Eric
Thanks,
Joseph
On 16/12/9 17:30, Eric Ren wrote:
The crash happens rather often when we reset some cluster
nodes while nodes contend fiercely to do truncate and append.
The crash backtr
one familiar with o2cb works out a patch for
o2cb in the future.
Does this sounds good to you?
Thanks,
Eric
Thanks,
Joseph
On 16/12/9 17:30, Eric Ren wrote:
The crash happens rather often when we reset some cluster
nodes while nodes contend fiercely to do truncate and append.
The crash backtr
he fix is quite straightforward. We keep to set DLM_LKF_VALBLK flag for
dlm_lock()
if the lock resource type needs LVB and the fsdlm plugin is uesed.
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/dlmglue.c | 10 ++
fs/ocfs2/stackglue.c | 6 ++
fs/ocfs2/stackglue.h |
ghtforward. We keep to set DLM_LKF_VALBLK flag for
dlm_lock()
if the lock resource type needs LVB and the fsdlm plugin is uesed.
Signed-off-by: Eric Ren
---
fs/ocfs2/dlmglue.c | 10 ++
fs/ocfs2/stackglue.c | 6 ++
fs/ocfs2/stackglue.h | 3 +++
3 files changed, 19 insertions
Sorry, this email is not delivered to Mark successfully because of one weird
character
trailing his email address somehow.
So, resend later...
Thanks,
Eric
On 12/09/2016 05:24 PM, Eric Ren wrote:
The crash happens rather often when we reset some cluster
nodes while nodes contend fiercely
Sorry, this email is not delivered to Mark successfully because of one weird
character
trailing his email address somehow.
So, resend later...
Thanks,
Eric
On 12/09/2016 05:24 PM, Eric Ren wrote:
The crash happens rather often when we reset some cluster
nodes while nodes contend fiercely
e needs LVB and the fsdlm plugin is uesed.
Signed-off-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/dlmglue.c | 10 ++
fs/ocfs2/stackglue.c | 6 ++
fs/ocfs2/stackglue.h | 3 +++
3 files changed, 19 insertions(+)
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..7
e needs LVB and the fsdlm plugin is uesed.
Signed-off-by: Eric Ren
---
fs/ocfs2/dlmglue.c | 10 ++
fs/ocfs2/stackglue.c | 6 ++
fs/ocfs2/stackglue.h | 3 +++
3 files changed, 19 insertions(+)
diff --git a/fs/ocfs2/dlmglue.c b/fs/ocfs2/dlmglue.c
index 83d576f..77d1632 100644
--- a/fs
Hi Geliang,
On 08/31/2016 08:23 PM, Geliang Tang wrote:
There are some repetitive code in jbd2_journal_init_dev() and
jbd2_journal_init_inode(). So this patch extracts the common code into
jbd2_journal_init() helper to simplify the code. And fix the coding
style warnings reported by
Hi Geliang,
On 08/31/2016 08:23 PM, Geliang Tang wrote:
There are some repetitive code in jbd2_journal_init_dev() and
jbd2_journal_init_inode(). So this patch extracts the common code into
jbd2_journal_init() helper to simplify the code. And fix the coding
style warnings reported by
On 02/29/2016 01:17 PM, Gang He wrote:
Implement online file check sysfile interfaces, e.g.
how to create the related sysfile according to device name,
how to display/handle file check request from the sysfile.
Signed-off-by: Gang He <g...@suse.com>
Tested-by: Eric Ren <z...
On 02/29/2016 01:17 PM, Gang He wrote:
Implement online file check sysfile interfaces, e.g.
how to create the related sysfile according to device name,
how to display/handle file check request from the sysfile.
Signed-off-by: Gang He
Tested-by: Eric Ren
---
fs/ocfs2/Makefile| 3
On 02/29/2016 01:18 PM, Gang He wrote:
Implement online check or fix inode block during
reading a inode block to memory.
Signed-off-by: Gang He <g...@suse.com>
Tested-by: Eric Ren <z...@suse.com>
---
fs/ocfs2/inode.c | 225 +++-
On 02/29/2016 01:18 PM, Gang He wrote:
Implement online check or fix inode block during
reading a inode block to memory.
Signed-off-by: Gang He
Tested-by: Eric Ren
---
fs/ocfs2/inode.c | 225 +++--
fs/ocfs2/ocfs2_trace.h | 2 +
2
94 matches
Mail list logo
