[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CD6925E8781EFD4D8E11882D20FC406D5280D382@SHSMSX104.ccr.corp.intel.com>
Date: Wed, 19 Jul 2017 08:13:22 +0000
From: "He, Bo" <bo.he@...el.com>
To: Felipe Balbi <balbi@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"peter.chen@....com" <peter.chen@....com>,
"k.opasiak@...sung.com" <k.opasiak@...sung.com>,
"stefan@...er.ch" <stefan@...er.ch>,
"felixhaedicke@....de" <felixhaedicke@....de>,
"colin.king@...onical.com" <colin.king@...onical.com>,
"rogerq@...com" <rogerq@...com>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"Zhang, Yanmin" <yanmin.zhang@...el.com>
Subject: RE: [PATCH] usb: gadget: udc: fix the kernel NULL pointer in
composite_setup
The patch I submitted is based on the latest kernel,
I checked the latest kernel has the same logic,
so I send the patch to LKML.
Thanks for your comments.
-----Original Message-----
From: Felipe Balbi [mailto:balbi@...nel.org]
Sent: Wednesday, July 19, 2017 3:51 PM
To: He, Bo <bo.he@...el.com>; linux-kernel@...r.kernel.org; linux-usb@...r.kernel.org
Cc: gregkh@...uxfoundation.org; peter.chen@....com; k.opasiak@...sung.com; stefan@...er.ch; felixhaedicke@....de; colin.king@...onical.com; rogerq@...com; f.fainelli@...il.com; Zhang, Yanmin <yanmin.zhang@...el.com>
Subject: RE: [PATCH] usb: gadget: udc: fix the kernel NULL pointer in composite_setup
Hi,
(please don't top-post and also break your lines at 80-columns ;-)
"He, Bo" <bo.he@...el.com> writes:
> 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.
That's fine, we, somehow, got a use-after-free on the tracepoints. I'm interested in fixing that without touching udc-core since that's a dwc3-only bug.
> 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.
Yeah, I need you to try v4.13-rc1. v4.4 is *really* old. I can't accept your patch unless I'm certain the bug still exists.
> 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.
Right, we also disable the interrupt on ->udc_stop(). See below:
static void __dwc3_gadget_stop(struct dwc3 *dwc) {
dwc3_gadget_disable_irq(dwc);
__dwc3_gadget_ep_disable(dwc->eps[0]);
__dwc3_gadget_ep_disable(dwc->eps[1]);
}
static int dwc3_gadget_stop(struct usb_gadget *g) {
struct dwc3 *dwc = gadget_to_dwc(g);
unsigned long flags;
int epnum;
spin_lock_irqsave(&dwc->lock, flags);
if (pm_runtime_suspended(dwc->dev))
goto out;
__dwc3_gadget_stop(dwc);
for (epnum = 2; epnum < DWC3_ENDPOINTS_NUM; epnum++) {
struct dwc3_ep *dep = dwc->eps[epnum];
if (!dep)
continue;
if (!(dep->flags & DWC3_EP_END_TRANSFER_PENDING))
continue;
wait_event_lock_irq(dep->wait_end_transfer,
!(dep->flags & DWC3_EP_END_TRANSFER_PENDING),
dwc->lock);
}
out:
dwc->gadget_driver = NULL;
spin_unlock_irqrestore(&dwc->lock, flags);
free_irq(dwc->irq_gadget, dwc->ev_buf);
return 0;
}
--
balbi
Powered by blists - more mailing lists