Linux-mtd Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Christoph Hellwig <hch@infradead.org>
To: Richard Weinberger <richard@nod.at>
Cc: Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com>,
	"dwmw2@infradead.org" <dwmw2@infradead.org>,
	"computersforpeace@gmail.com" <computersforpeace@gmail.com>,
	"dedekind1@gmail.com" <dedekind1@gmail.com>,
	"adrian.hunter@intel.com" <adrian.hunter@intel.com>,
	"michal.simek@xilinx.com" <michal.simek@xilinx.com>,
	Punnaiah Choudary Kalluri <punnaia@xilinx.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: UBIFS with dma on 4.6 kernel is not working
Date: Fri, 21 Oct 2016 05:53:13 -0700	[thread overview]
Message-ID: <20161021125313.GA16754@infradead.org> (raw)
In-Reply-To: <519a83bf-1244-5151-b873-bb8e1f2db3c6@nod.at>

On Fri, Oct 21, 2016 at 11:29:16AM +0200, Richard Weinberger wrote:
> DMA to vmalloced memory not good, it may work by chance if you transfer
> less than PAGE_SIZE.
> Especially on ARM.

DMA to vmalloc'ed or vmap memory is perfectly fine, you just have to be
very careful.

I would suggest to not expose the vmalloc address to the lower layers
that do DMA, but instead expose the pages, either as an array or
scatterlist.  Either allocate the pages using the normal page allocator
and then use vm_map_ram to generate a virtual address for them (that
is what XFS does for it's large metadata objects for example).  Or if
you can't do that iterate over the vmalloc address in page size chunks
and use vmalloc_to_page (we still also do that for one piece of legacy
cruft in XFS, but I'd rather avoid that for new designs).

  parent reply	other threads:[~2016-10-21 12:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-21  9:21 UBIFS with dma on 4.6 kernel is not working Naga Sureshkumar Relli
2016-10-21  9:29 ` Richard Weinberger
2016-10-21 11:57   ` Cyrille Pitchen
2016-10-21 12:53   ` Christoph Hellwig [this message]
2016-10-21 13:07     ` Richard Weinberger
2016-10-21 13:15       ` Christoph Hellwig
2016-10-24  7:08         ` Richard Weinberger
2016-10-25  5:52         ` Naga Sureshkumar Relli

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=20161021125313.GA16754@infradead.org \
    --to=hch@infradead.org \
    --cc=adrian.hunter@intel.com \
    --cc=computersforpeace@gmail.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=michal.simek@xilinx.com \
    --cc=naga.sureshkumar.relli@xilinx.com \
    --cc=punnaia@xilinx.com \
    --cc=richard@nod.at \
    /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