From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oliver Neukum Subject: Re: [PATCH 1/2 v5] usbnet: allow status interrupt URB to always be active Date: Fri, 12 Apr 2013 08:37:24 +0200 Message-ID: <1484183.xQu1D8fy8A@linux-5eaq.site> References: <20110727141246.GC29616@orbit.nwl.cc> <1735684.e8eeVoUkuq@linux-5eaq.site> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: Dan Williams , Elina Pasheva , Network Development , linux-usb , Rory Filer , Phil Sutter To: Ming Lei Return-path: In-Reply-To: Sender: linux-usb-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-Id: netdev.vger.kernel.org On Thursday 11 April 2013 20:59:05 Ming Lei wrote: > On Thu, Apr 11, 2013 at 8:28 PM, Oliver Neukum wrote: > > On Thursday 11 April 2013 20:11:13 Ming Lei wrote: > >> On Thu, Apr 11, 2013 at 7:14 PM, Oliver Neukum wrote: > >> > > >> > Sorry, I misunderstood. > >> > >> No problem, :-) > >> > >> > > >> > Task A Task B queue > >> > > >> > queue work > >> > request a reset > >> > allocate memory and block > >> > cancel the work > >> > shit happened > >> > >> If I understand the case correctly, the above deadlock can be avoided > >> by canceling rx/tx URBs at the end of pre_reset() or usbnet_disconnect(), > > > > No. cancel_work_sync() must wait for the work. The work will not finish. > > The work will complete when memory is reclaimed, and the rx/tx path is > still working, so memory reclaim can continue and the deadlock may not > be caused, may it? Only if the memory allocation goes to the same interface. If the blocking interface is storage, something bad happens (data loss not deadlock) Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html