linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Robin Murphy <robin.murphy@arm.com>
To: Thomas Hellstrom <thellstrom@vmware.com>,
	linux-graphics-maintainer@vmware.com, syeh@vmware.com
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/vmwgfx: Fix scatterlist unmapping
Date: Fri, 27 Apr 2018 17:56:00 +0100	[thread overview]
Message-ID: <8850b346-453f-e555-550d-7079b4f9d00d@arm.com> (raw)
In-Reply-To: <85d48f28-5df7-8c7e-d175-ce651838db53@vmware.com>

Hi Thomas,

On 25/04/18 14:21, Thomas Hellstrom wrote:
> Hi, Robin,
> 
> Thanks for the patch. It was some time since I put together that code, 
> but I remember hitting something similar to
> 
> https://www.linuxquestions.org/questions/linux-kernel-70/%27nents%27-argument-of-dma_unmap_sg-4175621964/ 
> 
> 
> Even if it's clear from the documentation that orig_nents should be used.

Hmmm, it's odd that you would see issues - it's always been something 
that CONFIG_DMA_API_DEBUG would have screamed about, and as far as I'm 
aware for x86, nents and orig_nents should always end up equal anyway. I 
would definitely be interested to see the specific fault details if it 
can be reproduced. I suppose one possibility is that there's some path 
where you inadvertently unmap something which was never mapped, but 
passing nents=0 means you manage to get away with it without the DMA API 
backend trying to interpret any bogus DMA addresses/lengths.

FWIW, the rationale is that sync_sg/unmap_sg operate on sg->page (which 
can always be translated back to a meaningful CPU address for 
cache/write buffer maintenance), not sg->dma_address (which sometimes 
cannot), therefore passing a truncated list will have the effect of just 
not syncing the tail end of the buffer, which is clearly bad.

Robin.

> 
> /Thomas
> 
> On 04/13/2018 05:14 PM, Robin Murphy wrote:
>> dma_unmap_sg() should be called with the same number of entries
>> originally passed to dma_map_sg(), not the number it returned, which may
>> be fewer. Admittedly this driver probably never runs on non-coherent
>> architectures where getting that wrong could lead to data loss, but it's
>> always good to be correct, and it's trivially easy to fix by just
>> restoring the SG table state before the call instead of afterwards.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>>
>> Found by inspection while poking around TTM users.
>>
>>   drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
>> b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
>> index 21111fd091f9..971223d39469 100644
>> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
>> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
>> @@ -369,9 +369,9 @@ static void vmw_ttm_unmap_from_dma(struct 
>> vmw_ttm_tt *vmw_tt)
>>   {
>>       struct device *dev = vmw_tt->dev_priv->dev->dev;
>> +    vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
>>       dma_unmap_sg(dev, vmw_tt->sgt.sgl, vmw_tt->sgt.nents,
>>           DMA_BIDIRECTIONAL);
>> -    vmw_tt->sgt.nents = vmw_tt->sgt.orig_nents;
>>   }
>>   /**
> 
> 

  reply	other threads:[~2018-04-27 16:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 15:14 [PATCH] drm/vmwgfx: Fix scatterlist unmapping Robin Murphy
2018-04-25 13:21 ` Thomas Hellstrom
2018-04-27 16:56   ` Robin Murphy [this message]
2018-04-27 17:39     ` Thomas Hellstrom
2018-04-30 11:42       ` Robin Murphy

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=8850b346-453f-e555-550d-7079b4f9d00d@arm.com \
    --to=robin.murphy@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-graphics-maintainer@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syeh@vmware.com \
    --cc=thellstrom@vmware.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).