[LU-8516] lock policy is changed for existing lock by resent

Duplicate — Tue, 23 Aug 2016 14:45:31 +0000

in ldlm_handle_enqueue0() there is special case for resent-reconstruct when lock exists:

	if (unlikely((flags & LDLM_FL_REPLAY) ||
		     (lustre_msg_get_flags(req->rq_reqmsg) & MSG_RESENT))) {
                /* Find an existing lock in the per-export lock hash */
		/* In the function below, .hs_keycmp resolves to
		 * ldlm_export_lock_keycmp() */
		/* coverity[overrun-buffer-val] */
                lock = cfs_hash_lookup(req->rq_export->exp_lock_hash,
                                       (void *)&dlm_req->lock_handle[0]);
                if (lock != NULL) {
                        DEBUG_REQ(D_DLMTRACE, req, "found existing lock cookie "
                                  LPX64, lock->l_handle.h_cookie);
			flags |= LDLM_FL_RESENT;
                        GOTO(existing_lock, rc = 0);
		}
        }

after that at existing_lock label:

	if (dlm_req->lock_desc.l_resource.lr_type != LDLM_PLAIN)
		ldlm_convert_policy_to_local(req->rq_export,
					dlm_req->lock_desc.l_resource.lr_type,
					&dlm_req->lock_desc.l_policy_data,
					&lock->l_policy_data);
	if (dlm_req->lock_desc.l_resource.lr_type == LDLM_EXTENT)
		lock->l_req_extent = lock->l_policy_data.l_extent;

This chunk of code will replace policy of already existing and granted lock to policy from incoming request.

For IBITS that means ibits replacement which is wrong at least because of skiplists which are based on mode and policy. Another bad effect is that the reconstructed reply will have lock with ibits from request but not ibits from its original processing on server.

IMHO, we shouldn't touch policy of existing lock at all and skip this code, will there be any side effect?

Whamcloud Community JIRA

[LU-8516] lock policy is changed for existing lock by resent