From: Matthew Wilcox <willy@infradead.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>,
Ming Lei <ming.lei@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Christoph Hellwig <hch@lst.de>, Ming Lei <tom.leiming@gmail.com>,
linux-block <linux-block@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"open list:XFS FILESYSTEM" <linux-xfs@vger.kernel.org>,
Dave Chinner <dchinner@redhat.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jens Axboe <axboe@kernel.dk>, Christoph Lameter <cl@linux.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: block: DMA alignment of IO buffer allocated from slab
Date: Mon, 24 Sep 2018 11:57:53 -0700 [thread overview]
Message-ID: <20180924185753.GA32269@bombadil.infradead.org> (raw)
In-Reply-To: <1537805984.195115.14.camel@acm.org>
On Mon, Sep 24, 2018 at 09:19:44AM -0700, Bart Van Assche wrote:
> That means that two buffers allocated with kmalloc() may share a cache line on
> x86-64. Since it is allowed to use a buffer allocated by kmalloc() for DMA, can
> this lead to data corruption, e.g. if the CPU writes into one buffer allocated
> with kmalloc() and a device performs a DMA write to another kmalloc() buffer and
> both write operations affect the same cache line?
You're not supposed to use kmalloc memory for DMA. This is why we have
dma_alloc_coherent() and friends. Also, from DMA-API.txt:
Memory coherency operates at a granularity called the cache
line width. In order for memory mapped by this API to operate
correctly, the mapped region must begin exactly on a cache line
boundary and end exactly on one (to prevent two separately mapped
regions from sharing a single cache line). Since the cache line size
may not be known at compile time, the API will not enforce this
requirement. Therefore, it is recommended that driver writers who
don't take special care to determine the cache line size at run time
only map virtual regions that begin and end on page boundaries (which
are guaranteed also to be cache line boundaries).
next prev parent reply other threads:[~2018-09-24 18:57 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-19 9:15 block: DMA alignment of IO buffer allocated from slab Ming Lei
2018-09-19 9:41 ` Vitaly Kuznetsov
2018-09-19 10:02 ` Ming Lei
2018-09-19 11:15 ` Vitaly Kuznetsov
2018-09-20 1:28 ` Ming Lei
2018-09-20 3:59 ` Yang Shi
2018-09-20 6:32 ` Christoph Hellwig
2018-09-20 6:31 ` Christoph Hellwig
2018-09-21 13:04 ` Vitaly Kuznetsov
2018-09-21 13:05 ` Christoph Hellwig
2018-09-21 15:00 ` Jens Axboe
2018-09-24 16:06 ` Christopher Lameter
2018-09-24 17:49 ` Jens Axboe
2018-09-24 18:00 ` Christopher Lameter
2018-09-24 18:09 ` Jens Axboe
2018-09-25 7:49 ` Dave Chinner
2018-09-25 15:44 ` Jens Axboe
2018-09-25 21:04 ` Matthew Wilcox
2018-09-23 22:42 ` Ming Lei
2018-09-24 9:46 ` Andrey Ryabinin
2018-09-24 14:19 ` Bart Van Assche
2018-09-24 14:43 ` Andrey Ryabinin
2018-09-24 15:08 ` Bart Van Assche
2018-09-24 15:52 ` Andrey Ryabinin
2018-09-24 15:58 ` Bart Van Assche
2018-09-24 16:07 ` Andrey Ryabinin
2018-09-24 16:19 ` Bart Van Assche
2018-09-24 16:47 ` Christopher Lameter
2018-09-24 18:57 ` Matthew Wilcox [this message]
2018-09-24 19:56 ` Bart Van Assche
2018-09-24 20:41 ` Matthew Wilcox
2018-09-24 20:54 ` Bart Van Assche
2018-09-24 21:09 ` Matthew Wilcox
2018-09-25 0:16 ` Ming Lei
2018-09-25 3:28 ` Matthew Wilcox
2018-09-25 4:10 ` Bart Van Assche
2018-09-25 4:44 ` Matthew Wilcox
2018-09-25 6:55 ` Ming Lei
2018-09-24 15:17 ` Christopher Lameter
2018-09-25 0:20 ` Ming Lei
2018-09-20 14:07 ` Bart Van Assche
2018-09-21 1:56 ` Dave Chinner
2018-09-21 7:08 ` Christoph Hellwig
2018-09-21 7:25 ` Ming Lei
2018-09-21 14:59 ` Jens Axboe
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=20180924185753.GA32269@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=aryabinin@virtuozzo.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=cl@linux.com \
--cc=dchinner@redhat.com \
--cc=gregkh@linuxfoundation.org \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=ming.lei@redhat.com \
--cc=tom.leiming@gmail.com \
--cc=torvalds@linux-foundation.org \
--cc=vkuznets@redhat.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;
as well as URLs for NNTP newsgroup(s).