On Wed, Feb 26, 2020 at 05:58:29PM +0000, Marciniszyn, Mike wrote: > > > > > > 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... I answered here: https://lore.kernel.org/linux-rdma/20200226141340.GF12414@unreal Anyway, I finally realized what I wanted to write and will send patch shortly. > > Mike
