-----Original Message----- From: Jason Gunthorpe <jgg@xxxxxxxxxx> Sent: Tuesday, February 15, 2022 8:42 AM To: Bob Pearson <rpearsonhpe@xxxxxxxxx> Cc: Bart Van Assche <bvanassche@xxxxxxx>; Guoqing Jiang <guoqing.jiang@xxxxxxxxx>; linux-rdma@xxxxxxxxxxxxxxx Subject: Re: Inconsistent lock state warning for rxe_poll_cq() On Mon, Feb 14, 2022 at 11:43:40PM -0600, Bob Pearson wrote: >> in the write_unlock_bh() call. This appears to complain if hardirqs >> are not enabled on the current cpu. This only happens if >> CONFIG_PROVE_LOCKING=y. > The trace shows this context is called within a irq disabled spinlock region. Ie this is trying to do > spinlock_irqsave() > write_lock_bh() > write_unlock_bh() > spinunlock_irqrestore() > Which is illegal locking. > Jason Yes. I figured that. But I don't know why, or why spin_lock_irqsave(lock_a) spin_lock_irqsave(lock_b) spin_unlock_irqrestore(lock_b) spin_unlock_irqrestore(lock_a) Is clearly better which has been suggested as a fix. Apparently someone above me is taking an irqsave lock and then calling Down to rxe_create_ah(). Calling the verbs APIs while holding a spinlock seems likely to cause problems. This looks to be in response to receiving a MAD so possibly is a call to ibv_create_ah_from_wc(). Bob
