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.
Thanks, Bart.
