> > > > You mean this one? https://marc.info/?l=linux- > > rdma&m=158263596831342&w=2 > > > > Ok. I will test the patch. > The patch definitely fixes the panic! I do have a question on the new pp state. In this use case, ipoib does the 0x71 (with pkey index and port) clears the pkey mask bit, and does the 0x51. The 0x1 is the state. The pkey index never changes. If a ulp did the 0x71, changed the pkey index, and then did the 0x51, what should end up in qp_pps? The state of 0 in new_pp I think will lose the different 0x51 pkey index. Here are some traces: [ 1316.849853] qp_attr_mask 71 qp_attr->port_num 1 qp->attr->pkey_index 0 [ 1316.857171] qp_pps ffff88905b58fd80 qp_pps->main.state 0 qp_pps->main.port_num 1 [ 1316.865454] new pp ffff889057fef0c0 state 1 port_num 1 pkey_index 0 [ 1316.872474] pp ffff889057fef0c0 pp->port_num 1 pp->pkey_index 0 [ 1316.902707] qp_attr_mask 51 qp_attr->port_num 1 qp->attr->pkey_index 0 [ 1316.910062] qp_pps ffff889057fef0c0 qp_pps->main.state 2 qp_pps->main.port_num 1 [ 1316.918347] new pp ffff889055e4fc00 state 0 port_num 1 pkey_index 0 <-- 0 state never gets inserted [ 1316.925365] port_pkey_list_insert main 0 [ 1316.929761] port_pkey_list_insert alt 0 [ 1316.934051] check_qp_port_pkey_settings 0 [ 1316.938542] ops.modify_qp 0 [ 1316.941674] new_pps ffff889055e4fc00 tmp_pps ffff889057fef0c0 [ 1316.948117] pp ffff889057fef0c0 pp->port_num 1 pp->pkey_index 0 > > Yes, this is what I wanted to achieve by "if (!(qp_attr_mask & > > (IB_QP_PKEY_INDEX || IB_QP_PORT)) && qp_pps) {" line. > > Was a non-bitwise || what was intended in this statememt? > > > I still have a question on the operator here... Mike
