> On 6 Apr 2020, at 20:10, Jason Gunthorpe <jgg@xxxxxxxxxxxx> wrote:
>
> On Mon, Apr 06, 2020 at 08:02:41PM +0200, Håkon Bugge wrote:
>
>>> However, I'm not sure what the state machine is supposed to look
>>> like..
>>
>> The neat state machines in Figure 13{5,6} in IBTA version 1.3. If you do not have it handy, I can send you the PDF off list.
>
> That is the IB CM state machine
>
> The RDMA CM I thought had extra things like this defered addr_resolve
> business
The "runway" before you can send a REQ is not captured by IBTA. So the {ADDR,ROUTE}_{QUERY,RESOLVED} states are not IBTA defined.
>>>> Shall I make a v2 base on next based on this idea, or do you have
>>>> something coming?
>>>
>>> Sure, I have nothing :)
>>>
>>> Also that rdma_destroy_id in addr_handler looks wrong.. ie we still
>>> retain pointers to the rdma_cm_id it destroys inside the struct
>>> ucma_context, don't we?
>>
>> On entry from user-space, we use the u32 id and looks it up in the
>> XArray. But if rdma_destoy_id() is called asynchronously called
>> between ucma_get_ctx_dev() and the de-reference of ctx->cm_id, we
>> are toast.
>
> Is that what happens on the addr_handler path?
No, there, the main problem is the revert of the state transitions. The first transition enables rdma_resolve_route() to pass its gate (i.e. state == ADDR_RESOLVED). Then it thinks the address is resolved, but the addr_handler changes its mind afterwards.
Thxs, Håkon
