On Fri, Dec 11, 2020 at 08:58:09AM +0100, Jinpu Wang wrote: > > > > No, I was wrong. I rechecked the code, it's not a valid deadlock, in > > > > cma_ib_req_handler, the conn_id is newly created in > > > > https://elixir.bootlin.com/linux/latest/source/drivers/infiniband/core/cma.c#L2185. > > > > > > > > Flush_workqueue will only flush close_work for any other cm_id, but > > > > not the newly created one conn_id, it has not associated with anything > > > > yet. > > > > > > > > The same applies to nvme-rdma. so it's a false alarm by lockdep. > > > > > > Leaving this without fix (proper lock annotation) is not right thing to > > > do, because everyone who runs rtrs code with LOCKDEP on will have same > > > "false alarm". > > > > > > So I recommend or not to take this patch or write it without LOCKDEP warning. > > Hi Leon, > > > > I'm thinking about the same, do you have a suggestion on how to teach > > LOCKDEP this is not really a deadlock, > > I do not know LOCKDEP well. > Found it myself, we can use lockdep_off > > https://elixir.bootlin.com/linux/latest/source/drivers/virtio/virtio_mem.c#L699 Gah, that is horrible. I'm not completely sure it is false either, at this point two handler_mutex's are locked (listening ID and the new ID) and there may be locking cycles that end up back on the listening ID, certainly it is not so simple. Jason
