[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-rdma
Subject:    RE: ib_destroy_cm_id() versus cm callback race ?
From:       "Hefty, Sean" <sean.hefty () intel ! com>
Date:       2012-04-30 19:27:01
Message-ID: 1828884A29C6694DAF28B7E6B8A8237346A00D4A () ORSMSX101 ! amr ! corp ! intel ! com
[Download RAW message or body]

> Are you sure that only one thread at a time will invoke a CM callback ? As
> far as I can see cm_recv_handler() queues work without checking whether
> any other work is ongoing. From drivers/infiniband/core/cm.c:

All callbacks for a single ID should be serialized.  (I think the listen ID is an \
exception, which would allow reporting multiple connection requests.)

cm_work_handler dispatches work to specific handlers based on the type of CM message. \
The serialization doesn't occur until we know which ID we're dealing with and its \
state.  See the cm_*_handler(work) calls.  
> What I have noticed could be explained by the following sequence of events:
> * IB CM core receives a connection request and invokes the callback for event
> IB_CM_REQ_RECEIVED.

The flow should be: cm_work_handler() -> cm_req_handler() -> cm_match_req(), which \
increments work_count (to 1 in this case).

> * That callback adds connection information to a global list (and keeps
> running).

Do you mean that the callback doesn't return to the CM?

> * User requests shutdown and hence from another thread ib_send_cm_dreq() is
> invoked.

ib_send_cm_dreq() at this point should fail with EINVAL, as the connection state is \
not yet established.  So, I don't think I'm quite following the operation yet.

> * IB CM core receives a DREP message and invokes the callback for event
> IB_CM_DREP_RECEIVED. That callback function gets confused because of the
> concurrent connection state manipulations by the IB_CM_REQ_RECEIVED handler
> (which is still running).

The cm_drep_handler() code increments work_count and checks the result.  If \
work_count was non-zero, then the DREP event should be queued on the id's work_list.  \
The thread which set work_count to 1, will eventually invoke the callback for that \
event.

- Sean

--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[prev in list] [next in list] [prev in thread] [next in thread]