From mboxrd@z Thu Jan 1 00:00:00 1970 From: James Bottomley Subject: Re: [Bug 9880] dma_free_coherent in arcmsr when calling areca tools Date: Sun, 03 Feb 2008 21:55:37 -0600 Message-ID: <1202097337.3318.143.camel@localhost.localdomain> References: <20080204030037.6C061108018@picon.linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: Received: from accolon.hansenpartnership.com ([76.243.235.52]:51063 "EHLO accolon.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754114AbYBDDzo (ORCPT ); Sun, 3 Feb 2008 22:55:44 -0500 In-Reply-To: <20080204030037.6C061108018@picon.linux-foundation.org> Sender: linux-scsi-owner@vger.kernel.org List-Id: linux-scsi@vger.kernel.org To: bugme-daemon@bugzilla.kernel.org, David Brownell , Russell King , Greg Kroah-Hartman Cc: linux-scsi@vger.kernel.org On Sun, 2008-02-03 at 19:00 -0800, bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9880 > Latest working kernel version: 2.6.23.12 > Earliest failing kernel version: 2.6.24 > Distribution: Gentoo > Hardware Environment: > Intel Core2Quad, 2GB Memory, Areca 1220ML > > Software Environment: > Areca CLI, Version: 1.72.250, Date: Apr 11 2007( Linux ) > Areca HTTP proxy server V1.81.250 for Areca RAID controllers. > > Problem Description: > > Feb 2 02:04:01 mrb WARNING: at arch/x86/kernel/pci-dma_64.c:169 > dma_free_coherent() > Feb 2 02:04:01 mrb Pid: 16080, comm: archttp64 Not tainted > 2.6.24 #1 > Feb 2 02:04:01 mrb > Feb 2 02:04:01 mrb Call Trace: > Feb 2 02:04:01 mrb [] dma_free_coherent+0x43/0x82 > Feb 2 02:04:01 mrb [] :arcmsr:arcmsr_queue_command > +0x379/0x973 > Feb 2 02:04:01 mrb [] _spin_unlock_irqrestore > +0x16/0x31 > Feb 2 02:04:01 mrb [] scsi_dispatch_cmd+0x194/0x1e9 > Feb 2 02:04:01 mrb [] scsi_request_fn+0x28b/0x360 > Feb 2 02:04:01 mrb [] blk_execute_rq_nowait+0x7a/0x8b > Feb 2 02:04:01 mrb [] scsi_execute_async+0x33d/0x36e > Feb 2 02:04:01 mrb [] :sg:sg_common_write+0x66f/0x6a3 > Feb 2 02:04:01 mrb [] :sg:sg_cmd_done+0x0/0x1fe > Feb 2 02:04:01 mrb [] _write_unlock_irqrestore > +0x17/0x34 > Feb 2 02:04:01 mrb [] :sg:sg_new_write+0x1f0/0x213 > Feb 2 02:04:01 mrb [] :sg:sg_ioctl+0x1f3/0x9f5 > Feb 2 02:04:01 mrb [] hrtimer_try_to_cancel+0x5f/0x68 > Feb 2 02:04:01 mrb [] hrtimer_cancel+0xc/0x16 > Feb 2 02:04:01 mrb [] do_nanosleep+0x55/0x7e > Feb 2 02:04:01 mrb [] do_ioctl+0x55/0x6b > Feb 2 02:04:01 mrb [] vfs_ioctl+0x233/0x24c > Feb 2 02:04:01 mrb [] sys_ioctl+0x51/0x71 > Feb 2 02:04:01 mrb [] system_call+0x7e/0x83 > > Steps to reproduce: > > If the httpd deamon runs the message occurs endless. > The areca cli command produces the message for each call. > > The problem occurs after upgrading to kernel 2.6.24 kernel 2.6.23.12 and before > works well. This is here, isn't it: void dma_free_coherent(struct device *dev, size_t size, void *vaddr, dma_addr_t bus) { WARN_ON(irqs_disabled()); /* for portability */ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ if (dma_ops->unmap_single) dma_ops->unmap_single(dev, bus, size, 0); free_pages((unsigned long)vaddr, get_order(size)); } That's caused by this commit: commit aa24886e379d2b641c5117e178b15ce1d5d366ba Author: David Brownell Date: Fri Aug 10 13:10:27 2007 -0700 dma_free_coherent() needs irqs enabled (sigh) I've cc'd the people responsible for this apparent bit of idiocy. Since the API addition to dma_alloc_coherent() was the GFP flags so you could call it from interrupt context with GFP_ATOMIC if so desired, (pci_dma_alloc_consistent always has GFP_ATOMIC semantics), why on earth would the corresponding free routine require non-atomic semantics? Is it seriously true that you can call dma_alloc_coherent() from atomic context on arm, but not dma_free_coherent()? James