Xue jiufei
2014-Jun-13 07:41 UTC
[Ocfs2-devel] [PATCH V2] ocfs2/dlm: fix misuse of list_move_tail() in dlm_run_purge_list()
When a lockres in purge list but is still in use, it should be moved to the tail of purge list. dlm_thread will continue to check next lockres in purge list. However, code list_move_tail(&dlm->purge_list, &lockres->purge) will do *no* movements, so dlm_thread will purge the same lockres in this loop again and again. If it is in use for a long time, other lockres will not be processed. Signed-off-by: Yiwen Jiang <jiangyiwen at huawei.com> Signed-off-by: joyce.xue <xuejiufei at huawei.com> --- fs/ocfs2/dlm/dlmthread.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/ocfs2/dlm/dlmthread.c b/fs/ocfs2/dlm/dlmthread.c index 9db869d..cf53a82 100644 --- a/fs/ocfs2/dlm/dlmthread.c +++ b/fs/ocfs2/dlm/dlmthread.c @@ -264,7 +264,7 @@ static void dlm_run_purge_list(struct dlm_ctxt *dlm, "used %d, state %d\n", dlm->name, lockres->lockname.len, lockres->lockname.name, !unused, lockres->state); - list_move_tail(&dlm->purge_list, &lockres->purge); + list_move_tail(&lockres->purge, &dlm->purge_list); spin_unlock(&lockres->spinlock); continue; } -- 1.8.3.4
Mark Fasheh
2014-Jun-13 21:18 UTC
[Ocfs2-devel] [PATCH V2] ocfs2/dlm: fix misuse of list_move_tail() in dlm_run_purge_list()
On Fri, Jun 13, 2014 at 03:41:59PM +0800, Xue jiufei wrote:> When a lockres in purge list but is still in use, it should be moved to > the tail of purge list. dlm_thread will continue to check next lockres > in purge list. However, code list_move_tail(&dlm->purge_list, > &lockres->purge) will do *no* movements, so dlm_thread will purge the > same lockres in this loop again and again. If it is in use for a long > time, other lockres will not be processed. > > Signed-off-by: Yiwen Jiang <jiangyiwen at huawei.com> > Signed-off-by: joyce.xue <xuejiufei at huawei.com>Oh didn't realize, this must be the fixed version of the patch? It might've been nice to label it V2 or something. Anyway, thanks for this. Please ignore my previous mail. Reviewed-by: Mark Fasheh <mfasheh at suse.de> -- Mark Fasheh