dlm: fix race between final callback and remove
authorAlexander Aring <aahringo@redhat.com>
Thu, 28 Mar 2024 15:48:41 +0000 (11:48 -0400)
committerDavid Teigland <teigland@redhat.com>
Mon, 1 Apr 2024 18:31:12 +0000 (13:31 -0500)
commit986ae3c2a8dfc1e229cabe9cc2e0b01b721c8980
tree6c036bb2a5ba03325b2c6c4ecca07d74c85bf958
parent0175e51b5134b55c89364aae68ec16271c67e472
dlm: fix race between final callback and remove

This patch fixes the following issue:

node 1 is dir
node 2 is master
node 3 is other

1->2: unlock
2: put final lkb, rsb moved to toss
2->1: unlock_reply
1: queue lkb callback with EUNLOCK
2->1: remove
1: receive_remove ignored (rsb on keep because of queued lkb callback)
1: complete lkb callback, put_lkb, move rsb to toss
3->1: lookup
1->3: lookup_reply master=2
3->2: request
2->3: request_reply EBADR

In summary:
An unexpected lkb reference causes the rsb to remain on the wrong list.
The rsb being on the wrong list causes receive_remove to be ignored.
An ignored receive_remove causes inconsistent dir and master state.

This sequence requires an unusually long delay in delivering the unlock
callback, because the remove message from 2->1 usually happens after
some seconds.  So, it's not known exactly how frequently this sequence
occurs in pratice.  It's possible that the same end result could also
have another unknown cause.

The solution for this issue is to further separate callback state
from the lkb, so that an lkb reference (and from that, an rsb ref)
are not held while a callback remains queued.  Then, within the
unlock_reply, the lkb will be freed and the rsb moved to the toss
list. So, the receive_remove will not be ignored.

Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
fs/dlm/ast.c
fs/dlm/ast.h
fs/dlm/dlm_internal.h
fs/dlm/lock.c
fs/dlm/user.c