From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752933Ab3F0Q5z (ORCPT ); Thu, 27 Jun 2013 12:57:55 -0400 Received: from smtp.codeaurora.org ([198.145.11.231]:45931 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752198Ab3F0Q5x (ORCPT ); Thu, 27 Jun 2013 12:57:53 -0400 Message-ID: <51CC6F10.3000202@codeaurora.org> Date: Thu, 27 Jun 2013 09:57:52 -0700 From: Stephen Boyd User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: balbi@ti.com CC: Vivek Gautam , linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org, Greg Kroah-Hartman Subject: Re: sleeping while atomic in dwc3_gadget_start References: <20130626215256.GC11625@codeaurora.org> <20130627065837.GL15455@arwen.pp.htv.fi> In-Reply-To: <20130627065837.GL15455@arwen.pp.htv.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/26/13 23:58, Felipe Balbi wrote: > On Wed, Jun 26, 2013 at 02:52:56PM -0700, Stephen Boyd wrote: >> Hi, >> >> I'm getting the folllowing BUG message on bootup with 3.10-rc5 >> >> BUG: sleeping function called from invalid context at mm/slub.c:926 >> in_atomic(): 1, irqs_disabled(): 128, pid: 1, name: swapper/0 >> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.10.0-rc5-gee3e35b-09316-ge78f3b35 #643 >> [] (unwind_backtrace+0x0/0x120) from [] (show_stack+0x10/0x14) >> [] (show_stack+0x10/0x14) from [] (kmem_cache_alloc_trace+0x3c/0x210) >> [] (kmem_cache_alloc_trace+0x3c/0x210) from [] (request_threaded_irq+0x88/0x11c) >> [] (request_threaded_irq+0x88/0x11c) from [] (dwc3_gadget_start+0x198/0x200) >> [] (dwc3_gadget_start+0x198/0x200) from [] (udc_bind_to_driver+0x70/0xd8) >> [] (udc_bind_to_driver+0x70/0xd8) from [] (usb_gadget_probe_driver+0x8c/0xb8) >> >> and I suspect this problem was introduced in commit 8698e2acf >> (usb: dwc3: gadget: introduce and use enable/disable irq >> methods). Is there a fix for this problem? Can we just move the >> irq request outside the spinlock? > nice :-) > > how about this ? If start fails do you call stop? I believe the answer is no, so we'll need to free_irq() somewhere along the error path. Or we can request it after the spin_unlock()? -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation