From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Shimoda, Yoshihiro" Subject: Re: [PATCH/RFC] usb: fix renesas_usbhs to not schedule in atomic context Date: Mon, 06 Feb 2012 17:52:33 +0900 Message-ID: <4F2F94D1.1080308@renesas.com> References: <1327589784-4287-1-git-send-email-g.liakhovetski@gmx.de> <1327589784-4287-2-git-send-email-g.liakhovetski@gmx.de> <4F22624E.2090201@renesas.com> <4F27CA7D.601@renesas.com> <4F2B9F34.60308@renesas.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from relmlor2.renesas.com (relmlor2.renesas.com [210.160.252.172]) by alsa0.perex.cz (Postfix) with ESMTP id 3BD83103920 for ; Mon, 6 Feb 2012 09:52:37 +0100 (CET) Received: from relmlir2.idc.renesas.com ([10.200.68.152]) by relmlor2.idc.renesas.com ( SJSMS) with ESMTP id <0LYY00MIQRBLVC00@relmlor2.idc.renesas.com> for alsa-devel@alsa-project.org; Mon, 06 Feb 2012 17:52:33 +0900 (JST) Received: from relmlac1.idc.renesas.com ([10.200.69.21]) by relmlir2.idc.renesas.com ( SJSMS) with ESMTP id <0LYY0008RRBLLMD0@relmlir2.idc.renesas.com> for alsa-devel@alsa-project.org; Mon, 06 Feb 2012 17:52:33 +0900 (JST) In-reply-to: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: alsa-devel-bounces@alsa-project.org Errors-To: alsa-devel-bounces@alsa-project.org To: Guennadi Liakhovetski Cc: alsa-devel@alsa-project.org, linux-sh@vger.kernel.org, Vinod Koul , Magnus Damm , linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Paul Mundt , linux-serial@vger.kernel.org List-Id: alsa-devel@alsa-project.org Hi Guennadi-san, 2012/02/04 0:43, Guennadi Liakhovetski wrote: > The current renesas_usbhs driver triggers > > BUG: scheduling while atomic: ksoftirqd/0/3/0x00000102 > > with enabled CONFIG_DEBUG_ATOMIC_SLEEP, by submitting DMA transfers from > an atomic (tasklet) context, which is not supported by the shdma dmaengine > driver. Fix it by switching to a work. Also simplify some list > manipulations. > > Signed-off-by: Guennadi Liakhovetski > --- > > Shimoda-san, this is the problem, that you were observing. However, it > exists with the present version of shdma just as well as with the new one > - on top of the simple DMA library. I marked it an RFC because (1) I only > lightly tested it with the gadget device on mackerel with the mass storage > gadget, and (2) I am somewhat concerned about races. Currently the work > function runs with no locking and there are no usual cancel_work_sync() > points in the patch. However, it has also been like this before with the > tasklet implementation, which is not much better, and it looks like there > are no asynchronous operations on the same packets like timeouts. Only > asynchronous events, that I can think about are things like unloading the > driver or unplugging the cable, but these have been there before too. It > would become worse on SMP, I think. Comments welcome. Thank you for the patch and comments. I also tested this patch using the g_mass_storage and g_ether. About your points, I think so, too. So, I will write such a code. Best regards, Yoshihiro Shimoda From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Shimoda, Yoshihiro" Date: Mon, 06 Feb 2012 08:52:33 +0000 Subject: Re: [PATCH/RFC] usb: fix renesas_usbhs to not schedule in atomic context Message-Id: <4F2F94D1.1080308@renesas.com> List-Id: References: <1327589784-4287-1-git-send-email-g.liakhovetski@gmx.de> <1327589784-4287-2-git-send-email-g.liakhovetski@gmx.de> <4F22624E.2090201@renesas.com> <4F27CA7D.601@renesas.com> <4F2B9F34.60308@renesas.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Guennadi Liakhovetski Cc: alsa-devel@alsa-project.org, linux-sh@vger.kernel.org, Vinod Koul , Magnus Damm , linux-usb@vger.kernel.org, linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org, Paul Mundt , linux-serial@vger.kernel.org Hi Guennadi-san, 2012/02/04 0:43, Guennadi Liakhovetski wrote: > The current renesas_usbhs driver triggers > > BUG: scheduling while atomic: ksoftirqd/0/3/0x00000102 > > with enabled CONFIG_DEBUG_ATOMIC_SLEEP, by submitting DMA transfers from > an atomic (tasklet) context, which is not supported by the shdma dmaengine > driver. Fix it by switching to a work. Also simplify some list > manipulations. > > Signed-off-by: Guennadi Liakhovetski > --- > > Shimoda-san, this is the problem, that you were observing. However, it > exists with the present version of shdma just as well as with the new one > - on top of the simple DMA library. I marked it an RFC because (1) I only > lightly tested it with the gadget device on mackerel with the mass storage > gadget, and (2) I am somewhat concerned about races. Currently the work > function runs with no locking and there are no usual cancel_work_sync() > points in the patch. However, it has also been like this before with the > tasklet implementation, which is not much better, and it looks like there > are no asynchronous operations on the same packets like timeouts. Only > asynchronous events, that I can think about are things like unloading the > driver or unplugging the cable, but these have been there before too. It > would become worse on SMP, I think. Comments welcome. Thank you for the patch and comments. I also tested this patch using the g_mass_storage and g_ether. About your points, I think so, too. So, I will write such a code. Best regards, Yoshihiro Shimoda From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754283Ab2BFIxK (ORCPT ); Mon, 6 Feb 2012 03:53:10 -0500 Received: from relmlor4.renesas.com ([210.160.252.174]:35030 "EHLO relmlor4.renesas.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751087Ab2BFIxH (ORCPT ); Mon, 6 Feb 2012 03:53:07 -0500 X-IronPort-AV: E=Sophos;i="4.73,369,1325430000"; d="scan'208";a="66780133" Message-id: <4F2F94D1.1080308@renesas.com> Date: Mon, 06 Feb 2012 17:52:33 +0900 From: "Shimoda, Yoshihiro" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-version: 1.0 To: Guennadi Liakhovetski Cc: linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org, Vinod Koul , Magnus Damm , linux-mmc@vger.kernel.org, alsa-devel@alsa-project.org, linux-serial@vger.kernel.org, Paul Mundt , linux-usb@vger.kernel.org Subject: Re: [PATCH/RFC] usb: fix renesas_usbhs to not schedule in atomic context References: <1327589784-4287-1-git-send-email-g.liakhovetski@gmx.de> <1327589784-4287-2-git-send-email-g.liakhovetski@gmx.de> <4F22624E.2090201@renesas.com> <4F27CA7D.601@renesas.com> <4F2B9F34.60308@renesas.com> In-reply-to: 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 Hi Guennadi-san, 2012/02/04 0:43, Guennadi Liakhovetski wrote: > The current renesas_usbhs driver triggers > > BUG: scheduling while atomic: ksoftirqd/0/3/0x00000102 > > with enabled CONFIG_DEBUG_ATOMIC_SLEEP, by submitting DMA transfers from > an atomic (tasklet) context, which is not supported by the shdma dmaengine > driver. Fix it by switching to a work. Also simplify some list > manipulations. > > Signed-off-by: Guennadi Liakhovetski > --- > > Shimoda-san, this is the problem, that you were observing. However, it > exists with the present version of shdma just as well as with the new one > - on top of the simple DMA library. I marked it an RFC because (1) I only > lightly tested it with the gadget device on mackerel with the mass storage > gadget, and (2) I am somewhat concerned about races. Currently the work > function runs with no locking and there are no usual cancel_work_sync() > points in the patch. However, it has also been like this before with the > tasklet implementation, which is not much better, and it looks like there > are no asynchronous operations on the same packets like timeouts. Only > asynchronous events, that I can think about are things like unloading the > driver or unplugging the cable, but these have been there before too. It > would become worse on SMP, I think. Comments welcome. Thank you for the patch and comments. I also tested this patch using the g_mass_storage and g_ether. About your points, I think so, too. So, I will write such a code. Best regards, Yoshihiro Shimoda