Hi, Balbi: 1. the issue reproduced very rarely, we run reboot test reproduce the issue, it reproduced two times on two board after more than 1500 cycles reboot. 2. the kernel version is 4.4, the test case is cold reboot, I think it's not android patches cause it, it's the interrupt thread run after the udc->driver->unbind. 3. I check more drivers, like amd5536_udc_stop, at91_stop, atmel_usba_stop, bcm63xx_udc_stop, s3c_hsudc_stop, all the interrupt disable will be in the udc_stop(), so we need guarantee to stop the interrupt then release the resource. -----Original Message----- From: Felipe Balbi [mailto:balbi@xxxxxxxxxx] Sent: Tuesday, July 18, 2017 6:44 PM To: He, Bo <bo.he@xxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx; linux-usb@xxxxxxxxxxxxxxx Cc: gregkh@xxxxxxxxxxxxxxxxxxx; peter.chen@xxxxxxx; k.opasiak@xxxxxxxxxxx; stefan@xxxxxxxx; felixhaedicke@xxxxxx; colin.king@xxxxxxxxxxxxx; rogerq@xxxxxx; f.fainelli@xxxxxxxxx; He, Bo <bo.he@xxxxxxxxx>; Zhang, Yanmin <yanmin.zhang@xxxxxxxxx> Subject: Re: [PATCH] usb: gadget: udc: fix the kernel NULL pointer in composite_setup Hi, "He, Bo" <bo.he@xxxxxxxxx> writes: > the patch is for fix the below kernel panic: > BUG: unable to handle kernel NULL pointer dereference at > 000000000000002a > IP: [<ffffffff8170e19d>] composite_setup+0x3d/0x1830 PGD 27525b067 PUD > 27525a067 PMD 0 > Oops: 0002 [#1] PREEMPT SMP > Call Trace: > [<ffffffff8168b902>] ? dwc3_trace+0x52/0x60 [<ffffffff810c504d>] ? > get_parent_ip+0xd/0x50 [<ffffffff8171159c>] android_setup+0xbc/0x140 > [<ffffffff810ec190>] ? irq_finalize_oneshot+0xe0/0xe0 > [<ffffffff816917e7>] dwc3_ep0_delegate_req+0x37/0x50 > [<ffffffff81692e69>] dwc3_ep0_interrupt+0xaf9/0xc10 > [<ffffffff810c504d>] ? get_parent_ip+0xd/0x50 [<ffffffff810ec190>] ? > irq_finalize_oneshot+0xe0/0xe0 [<ffffffff81690281>] > dwc3_thread_interrupt+0x931/0xbf0 [<ffffffff810ec190>] ? > irq_finalize_oneshot+0xe0/0xe0 [<ffffffff810ec1ae>] > irq_thread_fn+0x1e/0x40 [<ffffffff810ec674>] irq_thread+0x134/0x1b0 > [<ffffffff810ec260>] ? wake_threads_waitq+0x30/0x30 > [<ffffffff810b802d>] kthread+0xed/0x110 [<ffffffff81a2fd6f>] > ret_from_fork+0x3f/0x70 RIP [<ffffffff8170e19d>] > composite_setup+0x3d/0x1830 > > the root cause is dwc interrupt comes after usb_gadget_remove_driver. > the fix is stop udc to have the dwc3 disable the interrupt, then > release the resource in udc->driver->unbind. > usb_gadget_udc_stop--> > udc->gadget->ops->udc_stop(udc->gadget)--> > dwc3_gadget_stop > > Signed-off-by: he, bo <bo.he@xxxxxxxxx> > --- > drivers/usb/gadget/udc/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/usb/gadget/udc/core.c > b/drivers/usb/gadget/udc/core.c index e6f04ee..67e9aa5 100644 > --- a/drivers/usb/gadget/udc/core.c > +++ b/drivers/usb/gadget/udc/core.c > @@ -1258,8 +1258,8 @@ static void usb_gadget_remove_driver(struct > usb_udc *udc) > > usb_gadget_disconnect(udc->gadget); > udc->driver->disconnect(udc->gadget); > - udc->driver->unbind(udc->gadget); > usb_gadget_udc_stop(udc); > + udc->driver->unbind(udc->gadget); unbind must be called before udc_stop. This seems to be a bug *only* in dwc3. I can't see how this would happen, actually. On dwc3_gadget_stop() we mask dwc3's interrupts, so the handler should be executed anymore. Can you tell me how to reproduce this? I could try this out tomorrow. Which kernel are you using? I wonder if this is something caused by the Android patches. -- balbi -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
