From patchwork Fri May 17 12:34:23 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vinod Koul X-Patchwork-Id: 2582721 Return-Path: X-Original-To: patchwork-linux-arm@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork2.kernel.org Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by patchwork2.kernel.org (Postfix) with ESMTP id 3B8F8DF215 for ; Fri, 17 May 2013 13:10:56 +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 1UdKQw-0000cr-96; Fri, 17 May 2013 13:10:54 +0000 Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UdKQt-0005Ib-91; Fri, 17 May 2013 13:10:51 +0000 Received: from mga14.intel.com ([143.182.124.37]) by merlin.infradead.org with esmtp (Exim 4.80.1 #2 (Red Hat Linux)) id 1UdKQq-0005I5-K7 for linux-arm-kernel@lists.infradead.org; Fri, 17 May 2013 13:10:49 +0000 Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga102.ch.intel.com with ESMTP; 17 May 2013 06:09:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,692,1363158000"; d="scan'208";a="243014904" Received: from vkoul-udesk3.iind.intel.com ([10.223.84.41]) by AZSMGA002.ch.intel.com with ESMTP; 17 May 2013 06:09:54 -0700 Received: from vkoul-udesk3.iind.intel.com (localhost [127.0.0.1]) by vkoul-udesk3.iind.intel.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id r4HCYQth007668; Fri, 17 May 2013 18:04:26 +0530 Received: (from vkoul@localhost) by vkoul-udesk3.iind.intel.com (8.14.3/8.14.3/Submit) id r4HCYNwV007666; Fri, 17 May 2013 18:04:23 +0530 X-Authentication-Warning: vkoul-udesk3.iind.intel.com: vkoul set sender to vinod.koul@intel.com using -f Date: Fri, 17 May 2013 18:04:23 +0530 From: Vinod Koul To: Will Deacon Subject: Re: dmatest regression in 3.10-rc1 Message-ID: <20130517123423.GR14863@intel.com> References: <20130515152803.GL23869@mudshark.cambridge.arm.com> <20130516153553.GI11706@mudshark.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130516153553.GI11706@mudshark.cambridge.arm.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20130517_091048_805448_D2C42EFE X-CRM114-Status: GOOD ( 25.77 ) X-Spam-Score: -7.5 (-------) X-Spam-Report: SpamAssassin version 3.3.2 on merlin.infradead.org summary: Content analysis details: (-7.5 points) pts rule name description ---- ---------------------- -------------------------------------------------- -5.0 RCVD_IN_DNSWL_HI RBL: Sender listed at http://www.dnswl.org/, high trust [143.182.124.37 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: "andriy.shevchenko@linux.intel.com" , "viresh.kumar@linaro.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "djbw@fb.com" 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 On Thu, May 16, 2013 at 04:35:53PM +0100, Will Deacon wrote: > On Wed, May 15, 2013 at 04:28:03PM +0100, Will Deacon wrote: > > I've been observing a regression in the dmatest module with 3.10-rc1. It > > manifests as either: > > > > - a spurious timeout on one or more of the channel threads > > - a complete kernel lockup (loss of console) > > - a panic (see below, noting that the callback [dmatest_callback] is > > dereferencing a NULL pointer) > > > > If I revert 77101ce578bb ("dmatest: cancel thread immediately when asked > > for") then things are rosy again, but I'm not sure if this is hiding another > > problem. > > Right, so I think I understand what's causing this, but I'll leave it to > Andriy to suggest a fix. The problem comes about because the dmatest > module is now driven from debugfs, making it possible to unload the module > whilst a test run is in progress. In this case: > > - The DMA threads will return from wait_event_freezable_timeout(...) > due to kthread_should_stop() returning true, and subsequently > report failure because done.done is false. > > - The DMA engines may not be idle, so the asynchronous callback can > be invoked after we've started cleaning up, explaining the NULL > dereference I'm seeing. > > The solutions are either fixing the module exit code to cope with concurrent > DMA transfers or to revert 77101ce578bb and not allow the channel threads to > return mid-transfer. We need to properly abort the channels on removal. This is already handled in the code but the kthread_stop is called after the transactions are aborted. It should be the other way round. Can you try with below patch --- -- ~Vinod diff --git a/drivers/dma/dmatest.c b/drivers/dma/dmatest.c index d8ce4ec..4e8d581 100644 --- a/drivers/dma/dmatest.c +++ b/drivers/dma/dmatest.c @@ -822,6 +822,9 @@ static void dmatest_cleanup_channel(struct dmatest_chan *dtc) struct dmatest_thread *_thread; int ret; + /* terminate all transfers on specified channels */ + dmaengine_terminate_all(dtc->chan); + list_for_each_entry_safe(thread, _thread, &dtc->threads, node) { ret = kthread_stop(thread->task); pr_debug("dmatest: thread %s exited with status %d\n", @@ -830,9 +833,6 @@ static void dmatest_cleanup_channel(struct dmatest_chan *dtc) kfree(thread); } - /* terminate all transfers on specified channels */ - dmaengine_terminate_all(dtc->chan); - kfree(dtc); }