Hi Arvid,
I get the following kmemleak report coming from the ISP1760 driver:
unreferenced object 0xef42d000 (size 28):
comm "khubd", pid 189, jiffies 4294937550 (age 1421.040s)
hex dump (first 28 bytes):
00 01 10 00 00 02 20 00 08 d0 42 ef 08 d0 42 ef ...... ...B...B.
00 00 00 00 00 00 00 00 ff ff ff ff ............
backtrace:
[<c0080fe1>] create_object+0xa1/0x1ac
[<c007eac5>] kmem_cache_alloc+0x8d/0xdc
[<c01a9617>] isp1760_urb_enqueue+0x2ab/0x2f8
[<c019bbbd>] usb_hcd_submit_urb+0x75/0x574
[<c019d8f1>] usb_start_wait_urb+0x29/0x80
[<c019daad>] usb_control_msg+0x89/0xac
[<c0197f43>] hub_port_init+0x4fb/0x9c8
[<c0199c75>] hub_thread+0x5a1/0xd74
[<c0035acd>] kthread+0x69/0x6c
[<c000dc6d>] kernel_thread_exit+0x1/0x8
After some investigation, it looks like schedule_ptds() is called from
isp1760_irq() and removes the qh from the controlqhs queue but
ep->hcpriv still points to the qh and therefore it is not freed.
Shortly after this, the isp1760_endpoint_disable() function sets
ep->hcpriv to NULL and calls schedule_ptds() but since the corresponding
qh is no longer in the queue, it is simply forgotten and reported by
kmemleak.
Is there a race condition between isp1760_endpoint_disable and
isp1760_irq?
Thanks.
--
Catalin
--
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
