On 24/10/2022 10:25, Zhu Yanjun wrote:
+++ b/drivers/infiniband/sw/rxe/rxe_resp.c
@@ -778,6 +778,7 @@ static enum resp_states read_reply(struct rxe_qp *qp,
if (res->state == rdatm_res_state_new) {
if (!res->replay) {
mr = qp->resp.mr;
+ WARN_ON(!mr);
qp->resp.mr = NULL;
} else {
mr = rxe_recheck_mr(qp, res->read.rkey);
@@ -811,8 +812,7 @@ static enum resp_states read_reply(struct rxe_qp *qp,
rxe_mr_copy(mr, res->read.va, payload_addr(&ack_pkt),
payload, RXE_FROM_MR_OBJ);
- if (mr)
- rxe_put(mr);
+ rxe_put(mr);
if (bth_pad(&ack_pkt)) {
u8 *pad = payload_addr(&ack_pkt) + payload
--
2.31.1
Li is correct that the only way mr could be NULL is if qp->resp.mr == NULL. So the
What I am concerned about is if "WARN_ON(!mr);" should be added or not.
IMO, if the root cause remains unclear, this should be a problem.
Currently this problem is not fixed. It is useless to send a debug
statement to the maillist.
As per Bob's explanation, no 'WARN_ON(!mr)' is needed.
I will update the patch soon.
Zhu Yanjun
'if (mr)' is not needed if that is the case. The read_reply subroutine is reached
from a new rdma read operation after going through check_rkey or from a previous
rdma read operations from get_req if qp->resp.res != NULL or from a duplicate request
where the previous responder resource is found. In all these cases the mr is set.
Initially in check_rkey where if it can't find the mr it causes an RKEY_VIOLATION.
Thereafter the rkey is stored in the responder resources and looked up for each
packet to get an mr or cause an RKEY_VIOLATION. So the mr can't be NULL. I think
you can leave out the WARN and just drop the if (mr).
Very thanks for your explanation
Thanks
Zhijian
Bob
