Memory leak in isp1760-hcd.c

[Catalin Marinas]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/