IC, the PR request is coming from statfs which doesn't require global
bitmap i_mutex. So it looks good to me.
Reviewed-by: Joseph Qi
On 2015/12/24 3:20, Tariq Saeed wrote:
> Hi Joseph,
> Many threads doing this:
> PID: 6352 TASK: 8801a0a30100 CPU: 3 COMMAND: "nfsd"//blocked on same
> l
Hi Joseph,
Many threads doing this:
PID: 6352 TASK: 8801a0a30100 CPU: 3 COMMAND: "nfsd"//blocked on
same lock as 6323 , gen 0
#0 [8801a0a338d0] __schedule at 8150a954
#1 [8801a0a33978] schedule at 8150b0ef
#2 [8801a0a33988] schedule_timeout at 815
Hi Tariq,
As I know, global bitmap inode mutex will be held when doing allocation.
So how can it happen that EX and PR requests come concurrently int the
same node?
Thanks,
Joseph
On 2015/8/26 4:55, Tariq Saeed wrote:
> Orabug: 20933419
>
> NFS on a 2 node ocfs2 cluster each node exporting dir.
[Ocfs2-devel] [PATCH] NFS hangs in __ocfs2_cluster_lock due to
> race with ocfs2_unblock_lock
I added a cc:stable to this so it gets backported.
___
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel
ssage ----
> Subject: [Ocfs2-devel] [PATCH] NFS hangs in __ocfs2_cluster_lock due to race
> with ocfs2_unblock_lock
>Date: Tue, 25 Aug 2015 13:55:30 -0700
>From: Tariq Saeed
> To: ocfs2-devel@oss.oracle.com
> CC: mfas...@suse.de
>
>
>
&g
Hi,
Looks like this fell into through the cracks. This is a very real bug
encountered by Luminex Software and they tested the fix.
Regards
-Tariq
Forwarded Message
Subject: [Ocfs2-devel] [PATCH] NFS hangs in __ocfs2_cluster_lock due to
race with ocfs2_unblock_lock
Date
Orabug: 20933419
NFS on a 2 node ocfs2 cluster each node exporting dir. The lock causing
the hang is the global bit map inode lock. Node 1 is master, has
the lock granted in PR mode; Node 2 is in the converting list (PR ->
EX). There are no holders of the lock on the master node so it should
down
