Re: [PATCH] staging: usbip: stub_dev: Fixed oops during removal ofusbip_host

[Dan Carpenter]

On Tue, Sep 18, 2012 at 05:14:41PM +0530, navin patidar wrote:
> for usbip_host  event_handler()   handles following events.  defined
> in "usbip_common.h"
> 
>  1. SDEV_EVENT_REMOVED   (USBIP_EH_SHUTDOWN | USBIP_EH_RESET | USBIP_EH_BYE)
>  2. SDEV_EVENT_DOWN		(USBIP_EH_SHUTDOWN | USBIP_EH_RESET)
>  3. SDEV_EVENT_ERROR_TCP	(USBIP_EH_SHUTDOWN | USBIP_EH_RESET)
>  4. SDEV_EVENT_ERROR_SUBMIT	(USBIP_EH_SHUTDOWN | USBIP_EH_RESET)
>  5. VDEV_EVENT_ERROR_MALLOC (USBIP_EH_SHUTDOWN | USBIP_EH_UNUSABLE)
> 
> In case of events(1,2,3,4),  stub_shoutdown_connection() gets executed
> first and than stub_device_reset() .
> 
> In case of event 5, stub_shoutdown_connection()  kills kernel threads
> and stub_device_unusable()   changes devices status to
> "SDEV_ST_ERROR"(fatal error).
> 

It's case #5 which I would be worried about.  Where did the original
Oops happen?  I feel like it really would be helpful to see it.  I
don't see which check for ->status != SDEV_ST_AVAILABLE you're
talking about here which prevents the pointers from being reused...

>  thus stub_device_reset() can't  be called without
> stub_shutdown_connection(), so there is no problem of resource leak .

Except in the case of #5 obviously.

> you are also right, i could have set pointers to  NULL in
> stub_shutdown_connection() but i used  stub_device_reset() which is
> intended to reset usbip_device stuct member variables.
> 
> i'll resend patches, if maintainer ask for that.
> thanks
> 

Generally, that's normal.  If you want to ensure that a pointer
isn't used again then you clear it immediately.

I'm honestly just trying to figure this out.  When I saw that the
patch, I immediately thought *resource leak*.  I'm sorry that to
take your time up, but it shouldn't be that complicated that I have
to go tracking through the whole driver to understand this.

regards,
dan carpenter
--
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/