Re: [PATCH RFC 2/2] nvmet-rdma: use a separate lockdep class for the listening cm_id

[Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>]

On Nov 11, 2026 / 11:37, Jason Gunthorpe wrote:
> On Wed, Nov 11, 2026 at 02:01:58PM +0900, Shin'ichiro Kawasaki wrote:
> 
> > diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
> > index 337a49d1acf7..334f39c2f5e5 100644
> > --- a/drivers/infiniband/core/cma.c
> > +++ b/drivers/infiniband/core/cma.c
> > @@ -3949,6 +3949,12 @@ int rdma_listen(struct rdma_cm_id *id, int backlog)
> >  		container_of(id, struct rdma_id_private, id);
> >  	int ret;
> >  
> > +#ifdef CONFIG_DEBUG_LOCK_ALLOC
> > +	static struct lock_class_key cma_listen_handler_mutex_key;
> > +	lockdep_set_class(&id_priv->handler_mutex,
> > +			  &cma_listen_handler_mutex_key);
> > +#endif
> > +
> 
> This seems OK, I think we already have examples of this in CM IIRC?

Yes, I think so. siw and rxe drivers use dynamic lockdep classes for their
sockets:

$ git checkout v7.4-rc2
HEAD is now at 7475ea8b5861 Linux 7.4-rc2
$ cd drivers/infiniband/
$ git grep lock_class_key
sw/rxe/rxe_net.c:static struct lock_class_key rxe_recv_sk_key[2];
sw/rxe/rxe_net.c:static struct lock_class_key rxe_recv_slock_key[2];
sw/rxe/rxe_qp.c:static struct lock_class_key rxe_send_sk_key[2];
sw/rxe/rxe_qp.c:static struct lock_class_key rxe_send_slock_key[2];
sw/siw/siw_cm.c:static struct lock_class_key siw_sk_key[2];
sw/siw/siw_cm.c:static struct lock_class_key siw_slock_key[2];