ocfs2/dlm: dlmlock_remote() needs to account for remastery
authorSunil Mushran <sunil.mushran@oracle.com>
Sun, 24 Jul 2011 17:30:54 +0000 (10:30 -0700)
committerSunil Mushran <sunil.mushran@oracle.com>
Sun, 24 Jul 2011 17:30:54 +0000 (10:30 -0700)
commita2c0cc1579176bd0808ef7deea456767dfa80217
tree4f797a5fda954ce8a4783e9149da455879ca3641
parentff0a522e7db79625aa27a433467eb94c5e255718
ocfs2/dlm: dlmlock_remote() needs to account for remastery

In dlmlock_remote(), we wait for the resource to stop being active before
setting the inprogress flag. Active includes recovery, migration, etc.

The problem here is that if the resource was being recovered or migrated, the
new owner could very well be that node itself (and thus not a remote node).
This problem was observed in Oracle bug#12583620. The error messages observed
were as follows:

dlm_send_remote_lock_request:337 ERROR: Error -40 (ELOOP) when sending message 503 (key 0xd6d8c7) to node 2
dlmlock_remote:271 ERROR: dlm status = DLM_BADARGS
dlmlock:751 ERROR: dlm status = DLM_BADARGS

Signed-off-by: Sunil Mushran <sunil.mushran@oracle.com>
fs/ocfs2/dlm/dlmlock.c