On Wed, May 25, 2022 at 08:50:52PM +0200, Bart Van Assche wrote: > On 5/25/22 13:01, Sagi Grimberg wrote: > > iirc this was reported before, based on my analysis lockdep is giving > > a false alarm here. The reason is that the id_priv->handler_mutex cannot > > be the same for both cm_id that is handling the connect and the cm_id > > that is handling the rdma_destroy_id because rdma_destroy_id call > > is always called on a already disconnected cm_id, so this deadlock > > lockdep is complaining about cannot happen. > > > > I'm not sure how to settle this. > > If the above is correct, using lockdep_register_key() for > id_priv->handler_mutex instead of a static key should make the lockdep false > positive disappear. That only works if you can detect actual different lock classes during lock creation. It doesn't seem applicable in this case. Jason
