summaryrefslogtreecommitdiffstats
path: root/fs/mbcache.c
diff options
context:
space:
mode:
authorWengang Wang <wen.gang.wang@oracle.com>2010-07-30 16:14:44 +0800
committerJoel Becker <joel.becker@oracle.com>2010-08-07 10:49:41 -0700
commita524812b7eaa7783d7811198921100f079034e61 (patch)
treecbab978f01806cf71b20249519157a4044223c82 /fs/mbcache.c
parent845b6cf34150100deb5f58c8a37a372b111f2918 (diff)
downloadtalos-op-linux-a524812b7eaa7783d7811198921100f079034e61.tar.gz
talos-op-linux-a524812b7eaa7783d7811198921100f079034e61.zip
ocfs2/dlm: avoid incorrect bit set in refmap on recovery master
In the following situation, there remains an incorrect bit in refmap on the recovery master. Finally the recovery master will fail at purging the lockres due to the incorrect bit in refmap. 1) node A has no interest on lockres A any longer, so it is purging it. 2) the owner of lockres A is node B, so node A is sending de-ref message to node B. 3) at this time, node B crashed. node C becomes the recovery master. it recovers lockres A(because the master is the dead node B). 4) node A migrated lockres A to node C with a refbit there. 5) node A failed to send de-ref message to node B because it crashed. The failure is ignored. no other action is done for lockres A any more. For mormal, re-send the deref message to it to recovery master can fix it. Well, ignoring the failure of deref to the original master and not recovering the lockres to recovery master has the same effect. And the later is simpler. Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com> Acked-by: Srinivas Eeda <srinivas.eeda@oracle.com> Cc: stable@kernel.org Signed-off-by: Joel Becker <joel.becker@oracle.com>
Diffstat (limited to 'fs/mbcache.c')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud