[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.44L0.1501201022360.1150-100000@iolanthe.rowland.org>
Date: Tue, 20 Jan 2015 10:26:30 -0500 (EST)
From: Alan Stern <stern@...land.harvard.edu>
To: Olivier Sobrie <olivier@...rie.be>
cc: Jan Dumon <j.dumon@...ion.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
<linux-kernel@...r.kernel.org>, <linux-usb@...r.kernel.org>,
<netdev@...r.kernel.org>
Subject: Re: [PATCH 11/11] usb: core: fix a race with usb_queue_reset_device()
On Tue, 20 Jan 2015, Olivier Sobrie wrote:
> When usb_queue_reset() is called it schedules a work in view of
> resetting the usb interface. When the reset work is running, it
> can be scheduled again (e.g. by the usb disconnect method of
> the driver).
>
> Consider that the reset work is queued again while the reset work
> is running and that this work leads to a forced unbinding of the
> usb interface (e.g. because a driver is bound to the interface
> and has no pre/post_reset methods - see usb_reset_device()).
> In such condition, usb_unbind_interface() gets called and this
> function calls usb_cancel_queued_reset() which does nothing
> because the flag "reset_running" is set to 1. The second reset
> work that has been scheduled is therefore not cancelled.
> Later, the usb_reset_device() tries to rebind the interface.
> If it fails, then the usb interface context which contain the
> reset work struct is freed and it most likely crash when the
> second reset work tries to be run.
There was an earlier patch posted for testing (no results yet)
affecting this same region of code:
http://marc.info/?l=linux-usb&m=142064533924019&w=2
It should fix the problem described here, because (among other things)
it adds usb_get/put_intf calls to the delayed-reset routines.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists