From patchwork Mon Mar 10 09:08:48 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Wenyou Yang X-Patchwork-Id: 3801761 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 112EB9F369 for ; Mon, 10 Mar 2014 09:09:29 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 213F12024D for ; Mon, 10 Mar 2014 09:09:28 +0000 (UTC) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C97EF2024C for ; Mon, 10 Mar 2014 09:09:26 +0000 (UTC) Received: from merlin.infradead.org ([2001:4978:20e::2]) by casper.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WMwD1-0007oT-HJ; Mon, 10 Mar 2014 09:09:19 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1WMwCz-0007IJ-01; Mon, 10 Mar 2014 09:09:17 +0000 Received: from eusmtp01.atmel.com ([212.144.249.243]) by merlin.infradead.org with esmtps (Exim 4.80.1 #2 (Red Hat Linux)) id 1WMwCv-0007Gv-TJ for linux-arm-kernel@lists.infradead.org; Mon, 10 Mar 2014 09:09:14 +0000 Received: from apsmtp01.atmel.com (10.168.254.30) by eusmtp01.atmel.com (10.161.101.31) with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 10:08:49 +0100 Received: from PENCHT01.corp.atmel.com (10.168.5.161) by apsmtp01.corp.atmel.com (10.168.254.30) with Microsoft SMTP Server (TLS) id 14.2.347.0; Mon, 10 Mar 2014 17:16:10 +0800 Received: from PENMBX01.corp.atmel.com ([10.168.5.210]) by PENCHT01.corp.atmel.com ([fe80::95df:d3d0:4452:28e3%12]) with mapi id 14.02.0342.003; Mon, 10 Mar 2014 17:08:49 +0800 From: "Yang, Wenyou" To: "jiri.prchal@aksignal.cz" , Rabin Vincent , Alexandre Belloni Subject: RE: [BUG] atmel: spi: scheduling while atomic Thread-Topic: [BUG] atmel: spi: scheduling while atomic Thread-Index: AQHPN7ZJuHjjxaxCK0WADfcuEFuWcprQ7zyAgACbLgCABDF4AIAAHNCAgAOikYCAAJOfYA== Date: Mon, 10 Mar 2014 09:08:48 +0000 Message-ID: References: <5315E33C.5000205@aksignal.cz> <20140304214039.GA4441@piout.net> <5316CA84.4080907@aksignal.cz> <20140307225810.GB2918@piout.net> <531D73CB.7040402@aksignal.cz> In-Reply-To: <531D73CB.7040402@aksignal.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.5.13] MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20140310_050914_178211_07769EA2 X-CRM114-Status: GOOD ( 22.38 ) X-Spam-Score: -1.9 (-) Cc: "sboyd@codeaurora.org" , "Ferre, Nicolas" , "linux-arm-kernel@lists.infradead.org" X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.kernel.org@lists.infradead.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP > -----Original Message----- > From: Ji?í Prchal [mailto:jiri.prchal@aksignal.cz] > Sent: Monday, March 10, 2014 4:12 PM > To: Rabin Vincent; Alexandre Belloni; Yang, Wenyou > Cc: Ferre, Nicolas; linux-arm-kernel@lists.infradead.org; > sboyd@codeaurora.org > Subject: Re: [BUG] atmel: spi: scheduling while atomic > > Hi all, > at first: warning is on all spi devices. > at second: its with CONFIG_PREEMPT=y, without (# CONFIG_PREEMPT_RCU is > not set) is OK, but I wonder if this config will be fast enough for our > usage (nearly RT)? > > > Dne 8.3.2014 01:41, Rabin Vincent napsal(a): > > 2014-03-07 23:58 GMT+01:00 Alexandre Belloni > > : > >> On 05/03/2014 at 07:56:04 +0100, Ji?í Prchal wrote : > >>> [ 0.902343] BUG: scheduling while atomic: spi0/383/0x00000002 > >>> [ 0.906250] Modules linked in: > >>> [ 0.906250] CPU: 0 PID: 383 Comm: spi0 Not tainted 3.14.0- > rc4_cpm9g25+ #1 > >>> [ 0.906250] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > >>> [ 0.906250] [] (show_stack) from [] > (__schedule_bug+0x48/0x60) > >>> [ 0.906250] [] (__schedule_bug) from [] > (__schedule+0x60/0x484) > >>> [ 0.906250] [] (__schedule) from [] > (schedule_timeout+0x17c/0x1ac) > >>> [ 0.906250] [] (schedule_timeout) from [] > (wait_for_common+0x10c/0x1f0) > >>> [ 0.906250] [] (wait_for_common) from [] > (atmel_spi_transfer_one_message+0x71c/0xa48) > >>> [ 0.906250] [] (atmel_spi_transfer_one_message) from > [] (spi_pump_messages+0x210/0x238) > >>> [ 0.906250] [] (spi_pump_messages) from [] > (kthread_worker_fn+0x15c/0x1b4) > >>> [ 0.906250] [] (kthread_worker_fn) from [] > (kthread+0xb8/0xcc) > >>> [ 0.906250] [] (kthread) from [] > (ret_from_fork+0x14/0x24) > >>> [ 0.906250] at25 spi0.0: 128 KByte at25 eeprom, pagesize 512 > >> > >> Actually, I'm not quite sure how spi_pump_messages can be called from > an > >> atomic context. > > > > spi_pump_messages() is not called from atomic context. Rather, > > atmel_spi_transfer_one_message() does a spin_lock_irqsave() (via > > atmel_spi_lock()) and then calls atmel_spi_one_transfer(), which calls > > wait_for_completion_timeout(). That's why schedule is being called > > from atomic context. This was introduced by 8090d6d1a4 ("spi: atmel: > > Refactor spi-atmel to use SPI framework queue"). I think you should > > see the warning with CONFIG_PREEMPT=y. > > Thanks a lot for the report and analysis. --->8-------- From ba2dd7aee12cb09b9ef159251859443e1b055669 Mon Sep 17 00:00:00 2001 From: Wenyou Yang Date: Mon, 10 Mar 2014 16:44:33 +0800 Subject: [PATCH] spi: atmel: fix BUG: scheduling while atomic with CONFIG_PREEMPT=y introduced by 8090d6d1a415d3ae1a7208995decfab8f60f4f36 ("spi: atmel: Refactor spi-atmel to use SPI framework queue") Signed-off-by: Wenyou Yang --- drivers/spi/spi-atmel.c | 4 ++++ 1 file changed, 4 insertions(+) -- 1.7.9.5 ---<8---- This patch should fix this issue. I know it is not good one, the lock usage in the driver code should be double checked. Thanks. Best Regards, Wenyou Yang. diff --git a/drivers/spi/spi-atmel.c b/drivers/spi/spi-atmel.c index b0842f7..e05c3f2 100644 --- a/drivers/spi/spi-atmel.c +++ b/drivers/spi/spi-atmel.c @@ -1130,8 +1130,12 @@ static int atmel_spi_one_transfer(struct spi_master *master, atmel_spi_next_xfer_pio(master, xfer); } + atmel_spi_unlock(as); + ret = wait_for_completion_timeout(&as->xfer_completion, SPI_DMA_TIMEOUT); + atmel_spi_lock(as); + if (WARN_ON(ret == 0)) { dev_err(&spi->dev, "spi trasfer timeout, err %d\n", ret);