On Tue, Sep 26, 2023 at 10:11:16AM +0000, Chengfeng Ye wrote: > handle_receive_interrupt_napi_sp() running inside interrupt handler > could introduce inverse lock ordering between &dd->irq_src_lock > and &dd->uctxt_lock, if read_mod_write() is preempted by the isr. > > [CPU0] | [CPU1] > hfi1_ipoib_dev_open() | > --> hfi1_netdev_enable_queues() | > --> enable_queues(rx) | > --> hfi1_rcvctrl() | > --> set_intr_bits() | > --> read_mod_write() | > --> spin_lock(&dd->irq_src_lock) | > | hfi1_poll() > | --> poll_next() > | --> spin_lock_irq(&dd->uctxt_lock) > | > | --> hfi1_rcvctrl() > | --> set_intr_bits() > | --> read_mod_write() > | --> spin_lock(&dd->irq_src_lock) > <interrupt> | > --> handle_receive_interrupt_napi_sp() | > --> set_all_fastpath() | > --> hfi1_rcd_get_by_index() | > --> spin_lock_irqsave(&dd->uctxt_lock) | > > This flaw was found by an experimental static analysis tool I am > developing for irq-related deadlock. > > To prevent the potential deadlock, the patch use spin_lock_irqsave() > on &dd->irq_src_lock inside read_mod_write() to prevent the possible > deadlock scenario. > > Signed-off-by: Chengfeng Ye <dg573847474@xxxxxxxxx> > --- > drivers/infiniband/hw/hfi1/chip.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) Dennis? This needs your ack/nack Thanks, Jason
