mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Artem Bityutskiy <dedekind1@gmail.com>
Cc: Hong XU <hong.xu@atmel.com>,
	Nicolas Ferre <nicolas.ferre@atmel.com>,
	Patrice VILCHEZ <patrice.vilchez@atmel.com>,
	Linux Kernel list <linux-kernel@vger.kernel.org>,
	linux-mtd <linux-mtd@lists.infradead.org>,
	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
	Andrew Victor <linux@maxim.org.za>,
	"'linux-arm-kernel@lists.infradead.org'" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: Hit BUG_ON in dma-mapping.c:425 (RFC)
Date: Thu, 24 Mar 2011 09:41:22 +0000	[thread overview]
Message-ID: <20110324094122.GB19935@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20110324092732.GA19935@n2100.arm.linux.org.uk>

On Thu, Mar 24, 2011 at 09:27:32AM +0000, Russell King - ARM Linux wrote:
> I have no idea.  The problem comes down to MTDs interfaces being designed
> only for PIO - it's expected that the CPU places data into the virtual
> address being passed.  This virtual address can be a vmalloc address,
> a kmalloc'd address or a page address.
> 
> As long as that happens, everything all works because there's no cache
> aliasing problems to consider as the buffers are always accessed through
> the same mappings.
> 
> As soon as there's any attempt to move away from PIO, things get really
> sticky because, with *any* DMA noncoherent architecture (it's not limited
> to ARM) you run into issues with cache coherency causing data corruption.
> 
> When cache maintainence ends up having to deal with virtual addresses for
> one level of cache and physical addresses for subseqent levels, the
> problems are compounded even more.
> 
> The only real answer I can give is: if you want to deal with DMA, you
> absolutely must conform to the restrictions on DMA which means that you
> can't pass vmalloc addresses to the DMA API.
> 
> You can't work around that by converting a vmalloc address to a physical
> address and then its coresponding virtual page address as that means the
> DMA API will flush the wrong virtual address range and you'll again have
> cache incoherency.  That goes for *all* of the DMA API interfaces.

I should add - from asm-generic/dma-mapping-common.h:

static inline dma_addr_t dma_map_single_attrs(struct device *dev, void *ptr,
                                              size_t size,
                                              enum dma_data_direction dir,
                                              struct dma_attrs *attrs)
{
        struct dma_map_ops *ops = get_dma_ops(dev);
        dma_addr_t addr;

        kmemcheck_mark_initialized(ptr, size);
        BUG_ON(!valid_dma_direction(dir));
        addr = ops->map_page(dev, virt_to_page(ptr),
                             (unsigned long)ptr & ~PAGE_MASK, size,
                             dir, attrs);

And note that virt_to_page() only works for addresses in the kernel's
direct mapped memory region (iow, kmalloc et.al, not vmalloc).  The
above will probably go wrong silently (or maybe oops if you're lucky)
rather than BUG.  The difference is that on ARM we ensure that such bad
cases are always caught.

  reply	other threads:[~2011-03-24  9:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-05 16:49 Hit BUG_ON in dma-mapping.c:425 Nicolas Ferre
2011-01-05 16:55 ` Russell King - ARM Linux
2011-01-06 10:38   ` Nicolas Ferre
2011-01-06 11:19     ` Artem Bityutskiy
2011-03-24  8:18 ` Hit BUG_ON in dma-mapping.c:425 (RFC) Nicolas Ferre
2011-03-24  8:25   ` Russell King - ARM Linux
2011-03-24  8:36     ` Artem Bityutskiy
2011-03-24  9:27       ` Russell King - ARM Linux
2011-03-24  9:41         ` Russell King - ARM Linux [this message]
2011-03-24 11:08         ` Artem Bityutskiy

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=20110324094122.GB19935@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=dedekind1@gmail.com \
    --cc=hong.xu@atmel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux@maxim.org.za \
    --cc=nicolas.ferre@atmel.com \
    --cc=patrice.vilchez@atmel.com \
    --cc=plagnioj@jcrosoft.com \
    /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

all inboxes | Powered by JetHome®