linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Russell King <rmk@arm.linux.org.uk>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: bugme-daemon@bugzilla.kernel.org,
	David Brownell <david-b@pacbell.net>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	linux-scsi@vger.kernel.org
Subject: Re: [Bug 9880] dma_free_coherent in arcmsr when calling areca tools
Date: Mon, 4 Feb 2008 08:19:40 +0000	[thread overview]
Message-ID: <20080204081940.GC15955@flint.arm.linux.org.uk> (raw)
In-Reply-To: <1202097337.3318.143.camel@localhost.localdomain>

On Sun, Feb 03, 2008 at 09:55:37PM -0600, James Bottomley wrote:
> 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?

For the N-th time, when tearing down the MMU mappings which we need
to setup for coherent mappings, we need to invalidate the TLB.  On
SMP systems, that means doing an IPI to the other CPUs to tell them
to invalidate their TLBs as well.

Now, look at the restrictions on calling smp_call_function_on_cpu()
or equivalent function which is used to do the IPIs.  I don't care if
you look that up for x86 or ARM, because the restrictions are the same
- see the last two lines:

x86:
/**
 * smp_call_function_mask(): Run a function on a set of other CPUs.
 * @mask: The set of cpus to run on.  Must not include the current cpu.
 * @func: The function to run. This must be fast and non-blocking.
 * @info: An arbitrary pointer to pass to the function.
 * @wait: If true, wait (atomically) until function has completed on other CPUs. *
  * Returns 0 on success, else a negative status code.
 *
 * If @wait is true, then returns once @func has returned; otherwise
 * it returns just before the target cpu calls @func.
 *
 * You must not call this function with disabled interrupts or from a
 * hardware interrupt handler or from a bottom half handler.
 */

arm:
/*
 * You must not call this function with disabled interrupts, from a
 * hardware interrupt handler, nor from a bottom half handler.
 */


So, if the architecture requires you to IPI the TLB flush to other CPUs
this restriction has to propagate to dma_free_coherent.  Or we just don't
provide *any* DMA coherent memory and dictate that such platforms can
never use DMA.

Which is more idiotic?

> Is it seriously true that you can call dma_alloc_coherent() from atomic
> context on arm, but not dma_free_coherent()?

Yes.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

  parent reply	other threads:[~2008-02-04  8:20 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bug-9880-11613@http.bugzilla.kernel.org/>
2008-02-04  3:00 ` [Bug 9880] dma_free_coherent in arcmsr when calling areca tools bugme-daemon
2008-02-04  3:55   ` James Bottomley
2008-02-04  4:36     ` David Brownell
2008-02-04  8:19     ` Russell King [this message]
2008-02-09 16:51       ` James Bottomley
2008-02-09 17:21         ` Russell King
2008-02-09 17:33           ` James Bottomley
2008-02-04  3:55 ` bugme-daemon
2008-02-04  4:36 ` bugme-daemon
2008-02-04  8:20 ` bugme-daemon
2008-02-09 16:52 ` bugme-daemon
2008-02-09 17:24 ` bugme-daemon
2008-02-09 17:34 ` bugme-daemon
     [not found] <bug-9880-11613@https.bugzilla.kernel.org/>
2012-05-17 15:32 ` bugzilla-daemon
2012-05-17 15:32 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080204081940.GC15955@flint.arm.linux.org.uk \
    --to=rmk@arm.linux.org.uk \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=bugme-daemon@bugzilla.kernel.org \
    --cc=david-b@pacbell.net \
    --cc=gregkh@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).