From: Laura Abbott <labbott@redhat.com>
To: Liam Mark <lmark@codeaurora.org>, Sumit Semwal <sumit.semwal@linaro.org>
Cc: devel@driverdev.osuosl.org, "Todd Kjos" <tkjos@android.com>,
linux-kernel@vger.kernel.org, linaro-mm-sig@lists.linaro.org,
"Arve Hjønnevåg" <arve@android.com>,
"Martijn Coenen" <maco@android.com>
Subject: Re: [PATCH] staging: android: ion: Restrict cache maintenance to dma mapped memory
Date: Mon, 12 Feb 2018 12:39:33 -0800 [thread overview]
Message-ID: <d66b03aa-bb36-01b2-6b10-fdae3bcd4555@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1802092217010.2846@lmark-linux.qualcomm.com>
On 02/09/2018 10:21 PM, Liam Mark wrote:
> 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.
>
> Fix the ION begin_cpu_access and end_cpu_access functions to only apply
> cache maintenance to buffers which have been dma mapped.
>
I think this looks okay. I was initially concerned about concurrency and
setting the dma_mapped flag but I think that should be handled by the
caller synchronizing map/unmap/cpu_access calls (we might need to re-evaluate
in the future)
I would like to hold on queuing this for just a little bit until I
finish working on the Ion unit test (doing this in the complete opposite
order of course). I'm assuming this passed your internal tests Liam?
Thanks,
Laura
> 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 | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> index f480885e346b..e5df5272823d 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -214,6 +214,7 @@ struct ion_dma_buf_attachment {
> struct device *dev;caller
> struct sg_table *table;
> struct list_head list;
> + bool dma_mapped;
> };
>
> static int ion_dma_buf_attach(struct dma_buf *dmabuf, struct device *dev,
> @@ -235,6 +236,7 @@ static int ion_dma_buf_attach(struct dma_buf *dmabuf, struct device *dev,
>
> a->table = table;
> a->dev = dev;
> + a->dma_mapped = false;
> INIT_LIST_HEAD(&a->list);
>
> attachment->priv = a;
> @@ -272,6 +274,7 @@ static struct sg_table *ion_map_dma_buf(struct dma_buf_attachment *attachment,
> direction))
> return ERR_PTR(-ENOMEM);
>
> + a->dma_mapped = true;
> return table;
> }
>
> @@ -279,7 +282,10 @@ 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;
> +
> dma_unmap_sg(attachment->dev, table->sgl, table->nents, direction);
> + a->dma_mapped = false;
> }
>
> static int ion_mmap(struct dma_buf *dmabuf, struct vm_area_struct *vma)
> @@ -345,8 +351,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);
> }
> mutex_unlock(&buffer->lock);
>
> @@ -367,8 +374,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);
>
>
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
next prev parent reply other threads:[~2018-02-12 20:39 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-10 6:21 Liam Mark
2018-02-12 20:39 ` Laura Abbott [this message]
2018-02-12 20:39 ` Laura Abbott
2018-02-13 1:20 ` 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=d66b03aa-bb36-01b2-6b10-fdae3bcd4555@redhat.com \
--to=labbott@redhat.com \
--cc=arve@android.com \
--cc=devel@driverdev.osuosl.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lmark@codeaurora.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
Powered by JetHome