On Tue, Feb 09, 2021 at 02:46:48PM +0000, Chuck Lever wrote:
> Howdy-
>
> > On Aug 18, 2020, at 8:05 AM, Leon Romanovsky <leon@xxxxxxxxxx> wrote:
> >
> > From: Jason Gunthorpe <jgg@xxxxxxxxxx>
> >
> > In almost all cases rdma_accept() is called under the handler_mutex by
> > ULPs from their handler callbacks. The one exception was ucma which did
> > not get the handler_mutex.
>
> It turns out that the RPC/RDMA server also does not invoke rdma_accept()
> from its CM event handler.
>
> See net/sunrpc/xprtrdma/svc_rdma_transport.c:svc_rdma_accept()
>
> When lock debugging is enabled, the lockdep assertion in rdma_accept()
> fires on every RPC/RDMA connection.
>
> I'm not quite sure what to do about this.
Add the manual handler mutex calls like ucma did:
> > +void rdma_lock_handler(struct rdma_cm_id *id)
> > +{
> > + struct rdma_id_private *id_priv =
> > + container_of(id, struct rdma_id_private, id);
> > +
> > + mutex_lock(&id_priv->handler_mutex);
> > +}
> > +EXPORT_SYMBOL(rdma_lock_handler);
> > +
> > +void rdma_unlock_handler(struct rdma_cm_id *id)
> > +{
> > + struct rdma_id_private *id_priv =
> > + container_of(id, struct rdma_id_private, id);
> > +
> > + mutex_unlock(&id_priv->handler_mutex);
> > +}
> > +EXPORT_SYMBOL(rdma_unlock_handler);
But you need to audit carefully that this doesn't have messed up
concurrancy.. IIRC this means being careful that no events that could
be delivered before you get to accepting could have done something
they shouldn't do, like free the cm_id for instance.
Jason
