[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20120918131542.GR13767@mwanda>
Date: Tue, 18 Sep 2012 16:15:43 +0300
From: Dan Carpenter <dan.carpenter@...cle.com>
To: navin patidar <navinp@...c.in>
Cc: gregkh@...uxfoundation.org, mfm@...eddisk.com,
devel@...verdev.osuosl.org, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: usbip: stub_dev: Fixed oops during removal of
usbip_host
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists