From: Liam Mark <lmark@codeaurora.org>
To: labbott@redhat.com, sumit.semwal@linaro.org
Cc: arve@android.com, tkjos@android.com, maco@android.com,
joel@joelfernandes.org, christian@brauner.io,
devel@driverdev.osuosl.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
afd@ti.com, john.stultz@linaro.org,
Liam Mark <lmark@codeaurora.org>
Subject: [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory
Date: Fri, 18 Jan 2019 10:37:45 -0800 [thread overview]
Message-ID: <1547836667-13695-3-git-send-email-lmark@codeaurora.org> (raw)
In-Reply-To: <1547836667-13695-1-git-send-email-lmark@codeaurora.org>
The ION begin_cpu_access and end_cpu_access functions use the
dma_sync_sg_for_cpu and dma_sync_sg_for_device APIs to perform cache
maintenance.
Currently it is possible to apply cache maintenance, via the
begin_cpu_access and end_cpu_access APIs, to ION buffers which are not
dma mapped.
The dma sync sg APIs should not be called on sg lists which have not been
dma mapped as this can result in cache maintenance being applied to the
wrong address. If an sg list has not been dma mapped then its dma_address
field has not been populated, some dma ops such as the swiotlb_dma_ops ops
use the dma_address field to calculate the address onto which to apply
cache maintenance.
Also I don’t think we want CMOs to be applied to a buffer which is not
dma mapped as the memory should already be coherent for access from the
CPU. Any CMOs required for device access taken care of in the
dma_buf_map_attachment and dma_buf_unmap_attachment calls.
So really it only makes sense for begin_cpu_access and end_cpu_access to
apply CMOs if the buffer is dma mapped.
Fix the ION begin_cpu_access and end_cpu_access functions to only apply
cache maintenance to buffers which are dma mapped.
Fixes: 2a55e7b5e544 ("staging: android: ion: Call dma_map_sg for syncing and mapping")
Signed-off-by: Liam Mark <lmark@codeaurora.org>
---
drivers/staging/android/ion/ion.c | 26 +++++++++++++++++++++-----
1 file changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
index 6f5afab7c1a1..1fe633a7fdba 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -210,6 +210,7 @@ struct ion_dma_buf_attachment {
struct device *dev;
struct sg_table *table;
struct list_head list;
+ bool dma_mapped;
};
static int ion_dma_buf_attach(struct dma_buf *dmabuf,
@@ -231,6 +232,7 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf,
a->table = table;
a->dev = attachment->dev;
+ a->dma_mapped = false;
INIT_LIST_HEAD(&a->list);
attachment->priv = a;
@@ -261,12 +263,18 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
{
struct ion_dma_buf_attachment *a = attachment->priv;
struct sg_table *table;
+ struct ion_buffer *buffer = attachment->dmabuf->priv;
table = a->table;
+ mutex_lock(&buffer->lock);
if (!dma_map_sg(attachment->dev, table->sgl, table->nents,
- direction))
+ direction)) {
+ mutex_unlock(&buffer->lock);
return ERR_PTR(-ENOMEM);
+ }
+ a->dma_mapped = true;
+ mutex_unlock(&buffer->lock);
return table;
}
@@ -275,7 +283,13 @@ static void ion_unmap_dma_buf(struct dma_buf_attachment *attachment,
struct sg_table *table,
enum dma_data_direction direction)
{
+ struct ion_dma_buf_attachment *a = attachment->priv;
+ struct ion_buffer *buffer = attachment->dmabuf->priv;
+
+ mutex_lock(&buffer->lock);
dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
+ a->dma_mapped = false;
+ mutex_unlock(&buffer->lock);
}
static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
@@ -346,8 +360,9 @@ static int ion_dma_buf_begin_cpu_access(struct dma_buf *dmabuf,
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
- dma_sync_sg_for_cpu(a->dev, a->table->sgl, a->table->nents,
- direction);
+ if (a->dma_mapped)
+ dma_sync_sg_for_cpu(a->dev, a->table->sgl,
+ a->table->nents, direction);
}
unlock:
@@ -369,8 +384,9 @@ static int ion_dma_buf_end_cpu_access(struct dma_buf *dmabuf,
mutex_lock(&buffer->lock);
list_for_each_entry(a, &buffer->attachments, list) {
- dma_sync_sg_for_device(a->dev, a->table->sgl, a->table->nents,
- direction);
+ if (a->dma_mapped)
+ dma_sync_sg_for_device(a->dev, a->table->sgl,
+ a->table->nents, direction);
}
mutex_unlock(&buffer->lock);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2019-01-18 18:38 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 18:37 [PATCH 0/4] ION stability and perf changes Liam Mark
2019-01-18 18:37 ` [PATCH 1/4] staging: android: ion: Support cpu access during dma_buf_detach Liam Mark
2019-01-18 19:34 ` Andrew F. Davis
2019-01-18 20:40 ` Laura Abbott
2019-01-18 18:37 ` Liam Mark [this message]
2019-01-18 20:20 ` [PATCH 2/4] staging: android: ion: Restrict cache maintenance to dma mapped memory Andrew F. Davis
2019-01-18 21:18 ` Liam Mark
2019-01-29 23:44 ` Liam Mark
2019-01-30 11:31 ` Brian Starkey
2019-02-06 15:40 ` [Linaro-mm-sig] " Ørjan Eide
2019-02-07 7:31 ` Christoph Hellwig
2019-02-07 15:45 ` Ørjan Eide
2019-02-28 23:49 ` Liam Mark
2019-01-30 14:31 ` Andrew F. Davis
2019-01-18 18:37 ` [PATCH 3/4] dma-buf: add support for mapping with dma mapping attributes Liam Mark
2019-01-18 20:48 ` Laura Abbott
2019-01-18 21:32 ` Liam Mark
2019-01-18 22:45 ` Laura Abbott
2019-01-19 10:25 ` Christoph Hellwig
2019-01-19 16:50 ` Laura Abbott
2019-01-21 8:30 ` Christoph Hellwig
2019-01-21 19:44 ` Liam Mark
2019-01-21 19:49 ` Andrew F. Davis
2019-01-21 20:20 ` Liam Mark
2019-01-21 20:24 ` Andrew F. Davis
2019-01-21 22:18 ` Liam Mark
2019-01-22 15:42 ` Andrew F. Davis
2019-01-22 22:47 ` Liam Mark
2019-01-21 21:30 ` Christoph Hellwig
2019-01-21 22:14 ` Liam Mark
2019-01-21 21:29 ` Christoph Hellwig
2019-01-21 22:12 ` Liam Mark
2019-01-22 16:06 ` Andrew F. Davis
2019-01-22 22:50 ` Liam Mark
2019-01-18 18:37 ` [PATCH 4/4] staging: android: ion: Support " Liam Mark
2019-01-21 12:19 ` Brian Starkey
2019-01-22 22:37 ` Liam Mark
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=1547836667-13695-3-git-send-email-lmark@codeaurora.org \
--to=lmark@codeaurora.org \
--cc=afd@ti.com \
--cc=arve@android.com \
--cc=christian@brauner.io \
--cc=devel@driverdev.osuosl.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=joel@joelfernandes.org \
--cc=john.stultz@linaro.org \
--cc=labbott@redhat.com \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maco@android.com \
--cc=sumit.semwal@linaro.org \
--cc=tkjos@android.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