All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jon Medhurst (Tixy)" <tixy@linaro.org>
To: Laura Abbott <labbott@redhat.com>
Cc: "Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Riley Andrews" <riandrews@android.com>,
	"Liviu Dudau" <Liviu.Dudau@arm.com>,
	devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org,
	"Robin Murphy" <robin.murphy@arm.com>
Subject: Re: [PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer
Date: Thu, 21 Jan 2016 20:19:19 +0000	[thread overview]
Message-ID: <1453407559.2858.77.camel@linaro.org> (raw)
In-Reply-To: <56A117B6.7050503@redhat.com>

On Thu, 2016-01-21 at 09:39 -0800, Laura Abbott wrote:
> On 01/21/2016 03:57 AM, Jon Medhurst (Tixy) wrote:
> > From: Liviu Dudau <Liviu.Dudau@arm.com>
> >
> > ion_buffer_create() will allocate a buffer and then create a DMA
> > mapping for it, but it forgot to set the length of the page entries.
> >
> > Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
> > Signed-off-by: Jon Medhurst <tixy@linaro.org>
> > ---
> >   drivers/staging/android/ion/ion.c | 4 +++-
> >   1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/staging/android/ion/ion.c b/drivers/staging/android/ion/ion.c
> > index e237e9f..df56021 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -251,8 +251,10 @@ static struct ion_buffer *ion_buffer_create(struct ion_heap *heap,
> >   	 * memory coming from the heaps is ready for dma, ie if it has a
> >   	 * cached mapping that mapping has been invalidated
> >   	 */
> > -	for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i)
> > +	for_each_sg(buffer->sg_table->sgl, sg, buffer->sg_table->nents, i) {
> >   		sg_dma_address(sg) = sg_phys(sg);
> > +		sg_dma_len(sg) = sg->length;
> > +	}
> >   	mutex_lock(&dev->buffer_lock);
> >   	ion_buffer_add(dev, buffer);
> >   	mutex_unlock(&dev->buffer_lock);
> >
> 
> So Ion is really doing it wrong by setting the sg_dma_address manually as
> the comment above notes. Ion has moved away from sg_dma_len though
> (see 06e0dcaeb4fd72a010a1f5ad0c03abd8e0a58ef9). This isn't technically
> a mapping as well. What's broken by not having sg_dma_len set?

I fear this could end up being embarrassing...

What's broken is that the out-of-tree kernel driver for ARM's Mali GPU
is getting passed a dma_buf corresponding to the ION buffer. It is then
calling dma_buf_map_attachment [1] on that and then parsing the
resultant scatter-gather list to get the physical pages so it can pass
them to the GPU hardware. In the process, it is using sg_dma_len() to
get the length, which is garbage for ION buffers if ion_buffer_create()
doesn't set it.

[1] http://git.linaro.org/landing-teams/working/arm/kernel-release.git/blob/9660bff61ab296be02aad111d0bc2b9919493de5:/drivers/gpu/arm/midgard/mali_kbase_jd.c#l333

Now, I just tried making the Mali driver use sg->length rather than 
sg_dma_len() and, unsurprisingly, that also fixes the problem. So, my
questions would be...

Is it acceptable for a driver getting a dma_buf to parse the
scatter-gather list for that by had?

If so, should it use ->length or sg_dma_len() to get the length of each
element?

If sg_dma_len() is correct or acceptable then it seems to me that the
ION code should set that length. Especially as the comment in the code
implies it's faking a call to map_sg and grepping the kernel tree for
real implementations of that functionality seems to show the dma_address
getting set.

As you can probably tell, I feel I may be on shaky ground. This is
because I don't fully understanding the code and suspecting both the ION
and GPU code is rather dodgy (and possibly the bits in between :-)

-- 
Tixy

  reply	other threads:[~2016-01-21 20:19 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21 11:57 [PATCH] staging: android: ion: Set the length of the DMA sg entries in buffer Jon Medhurst (Tixy)
2016-01-21 17:39 ` Laura Abbott
2016-01-21 20:19   ` Jon Medhurst (Tixy) [this message]
2016-01-22  0:58     ` Laura Abbott
2016-01-22  9:43       ` Jon Medhurst (Tixy)

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=1453407559.2858.77.camel@linaro.org \
    --to=tixy@linaro.org \
    --cc=Liviu.Dudau@arm.com \
    --cc=arve@android.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=labbott@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=riandrews@android.com \
    --cc=robin.murphy@arm.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.