> -----Original Message-----
> From: linux-rdma-owner@xxxxxxxxxxxxxxx <linux-rdma-owner@xxxxxxxxxxxxxxx>
> On Behalf Of Jason Gunthorpe
> Sent: Wednesday, August 22, 2018 11:13 PM
> To: Chuck Lever <chuck.lever@xxxxxxxxxx>
> Cc: linux-rdma <linux-rdma@xxxxxxxxxxxxxxx>
> Subject: Re: CM event handler: process or IRQ context?
>
> On Tue, Aug 14, 2018 at 10:41:19AM -0400, Chuck Lever wrote:
> > Hi-
> >
> > /**
> > * rdma_create_id - Create an RDMA identifier.
> > *
> > * @net: The network namespace in which to create the new id.
> > * @event_handler: User callback invoked to report events associated with the
> > * returned rdma_id.
> > * @context: User specified context associated with the id.
> > * @ps: RDMA port space.
> > * @qp_type: type of queue pair associated with the id.
> > *
> > * The id holds a reference on the network namespace until it is destroyed.
> > */
> > #define rdma_create_id(net, event_handler, context, ps, qp_type)
> >
> > Is it guaranteed that the @event_handler function is called in a
> > process context? Code audit suggests it's always a delayed worker
> > thread, thus it would always be safe to use spin_lock_bh in the event
> > handler function.
> >
This is my conclusion too. Rdmacm holds mutex while calling event handler.
I have code refactor for locking in progress in cma.c (at really slow pace). However I do not intent to change calling context.
> > Same question for the consumer's QP event handler:
> >
> > struct ib_qp_init_attr {
> > void (*event_handler)(struct ib_event *, void *);
> >
> > Thanks in advance.
>
Qp event handler can be called from non blocking context.
> If you find out please add a comment :)
Yes. Its worth the addition, apart from context what should/can be done specially with rdma_cm_id.
