[LU-8516] lock policy is changed for existing lock by resent Created: 19/Aug/16  Updated: 23/Aug/16  Resolved: 23/Aug/16

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Mikhail Pershin Assignee: Mikhail Pershin
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
duplicates LU-8349 MDS crash ldlm_flock.c:849:ldlm_expor... Resolved
Severity: 3
Rank (Obsolete): 9223372036854775807

 Description   

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?



 Comments   
Comment by Gerrit Updater [ 19/Aug/16 ]

Mike Pershin (mike.pershin@intel.com) uploaded a new patch: http://review.whamcloud.com/22028
Subject: LU-8516 ldlm: don't change lock policy from resent
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 9fd0964d907663e5099c5a6d121161e3d3ee7e92

Comment by Mikhail Pershin [ 23/Aug/16 ]

solved already in LU-8349

Generated at Sat Feb 10 02:18:15 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.