If a lkb is timed out when dlm_scan_timeout() kicks in and removes a timed out lkb from ls->ls_timeout list the next iteration can end in timeout the same lkb again that shouldn't happen. Since commit dc1acd5c9469 ("dlm: replace usage of found with dedicated list iterator variable") we don't set the lkb variable before the inner lookup loop to NULL. The outer loop will not stop and checks if there was a successful lookup with the lkb pointer of the last iteration that wasn't set to NULL. To stop this behavior we use the old condition "!do_cancel && !do_warn" which signals if there was a successful lookup and the lkb variable should be set with the lkb that was looked up to be timed out. If the condition is false there is no timed out lkb in ls->ls_timeout and the outer loop stops.
Cc: stable@vger.kernel.org Reported-by: Marc Smith msmith626@gmail.com Fixes: dc1acd5c9469 ("dlm: replace usage of found with dedicated list iterator variable") Signed-off-by: Alexander Aring aahringo@redhat.com --- fs/dlm/lock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/dlm/lock.c b/fs/dlm/lock.c index 226822f49d30..1ff842be5891 100644 --- a/fs/dlm/lock.c +++ b/fs/dlm/lock.c @@ -1919,7 +1919,7 @@ void dlm_scan_timeout(struct dlm_ls *ls) } mutex_unlock(&ls->ls_timeout_mutex);
- if (!lkb) + if (!do_cancel && !do_warn) break;
r = lkb->lkb_resource;