On Sat, Jul 29, 2023 at 09:26:34AM +0000, Chengfeng Ye wrote: > &oxu->mem_lock is acquired by isr oxu_irq() along the below call > chain under hardirq context. > > <hard interrupt> > -> oxu_irq() > -> oxu210_hcd_irq() > -> ehci_work() > -> scan_async() > -> qh_completions() > -> oxu_murb_free() > -> spin_lock(&oxu->mem_lock) > > Thus the acquisition of the lock under process context should disable > irq, otherwise deadlock could happen if the irq happens to preempt the > execution while the lock is held in process context on the same CPU. > > This flaw was found by an experimental static analysis tool I am developing > for irq-related deadlock. x86_64 allmodconfig using gcc shows no new > warning. > > The patch fixes the potential deadlocks by using spin_lock_irqsave() on > &oxu->mem_lock > > Signed-off-by: Chengfeng Ye <dg573847474@xxxxxxxxx> > > Changes in v2 > - use spin_lock_irqsave() on more potential deadlock sites of &oxu->mem_lock This needs to be below the --- line, as documented, so it doesn't show up in the changelog. How did you test this change? Do you have hardware to test it out? If not, I don't think we can accpet this, see the kernel documentation for what we accept from tools and researchers. thanks, greg k-h
