All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Zimmermann <tzimmermann@suse.de>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Gerd Hoffmann <kraxel@redhat.com>,
	dri-devel@lists.freedesktop.org
Subject: Re: [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
Date: Tue, 12 Nov 2019 10:49:21 +0100	[thread overview]
Message-ID: <06f1f400-2e20-5c40-c0ea-967f1ab2b787@suse.de> (raw)
In-Reply-To: <20191112093246.GD23790@phenom.ffwll.local>


[-- Attachment #1.1.1: Type: text/plain, Size: 6600 bytes --]

Hi

Am 12.11.19 um 10:32 schrieb Daniel Vetter:
> On Tue, Nov 12, 2019 at 10:26:44AM +0100, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 08.11.19 um 17:27 schrieb Daniel Vetter:
>>> On Fri, Oct 25, 2019 at 09:30:42AM +0200, Daniel Vetter wrote:
>>>> On Thu, Oct 24, 2019 at 02:18:59PM -0500, Rob Herring wrote:
>>>>> Commit c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
>>>>> introduced a GEM object mmap() hook which is expected to subtract the
>>>>> fake offset from vm_pgoff. However, for mmap() on dmabufs, there is not
>>>>> a fake offset.
>>>>>
>>>>> To fix this, let's always call mmap() object callback with an offset of 0,
>>>>> and leave it up to drm_gem_mmap_obj() to remove the fake offset.
>>>>>
>>>>> TTM still needs the fake offset, so we have to add it back until that's
>>>>> fixed.
>>>>>
>>>>> Fixes: c40069cb7bd6 ("drm: add mmap() to drm_gem_object_funcs")
>>>>> Cc: Gerd Hoffmann <kraxel@redhat.com>
>>>>> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>> Signed-off-by: Rob Herring <robh@kernel.org>
>>>>> ---
>>>>> v2:
>>>>> - Move subtracting the fake offset out of mmap() obj callbacks.
>>>>>
>>>>> I've tested shmem, but not ttm. Hopefully, I understood what's needed 
>>>>> for TTM.
>>>
>>> So unfortunately I'm already having regrets on this. We might even have
>>> broken some of the ttm drivers here.
>>>
>>> Trouble is, if you need to shoot down userspace ptes of a bo (because it's
>>> getting moved or whatever), then we do that with unmap_mapping_range.
>>> Which means each bo needs to be mapping with a unique (offset,
>>> adress_space), or it won't work. By remapping all the bo to 0 we've broken
>>> this. We've also had this broken this for a while for the simplistic
>>> dma-buf mmap, since without any further action we'll reuse the address
>>> space of the dma-buf inode, not of the drm_device.
>>>
>>> Strangely both etnaviv and msm have a comment to that effect - grep for
>>> unmap_mapping_range. But neither actually uses it.
>>>
>>> Not exactly sure what's the best course of action here now.
>>>
>>> Also adding Thomas Zimmermann, who's worked on all the vram helpers.
>>
>> VRAM helpers use drm_gem_ttm_mmap(), which wraps ttm_bo_mmap_obj().
>> These changes should be transparent.
> 
> There's still the issue that for dma-buf mmap vs drm mmap you use
> different f_mapping, which means ttm's pte shootdown won't work correctly
> for dma-buf mmaps. But yeah normal operation for ttm/vram helpers should
> be fine.

VRAM helpers don't support dmabufs.

Best regards
Thomas

> -Daniel
> 
>>
>> Best regards
>> Thomas
>>
>>> -Daniel
>>>
>>>>>
>>>>> Rob
>>>>>
>>>>>  drivers/gpu/drm/drm_gem.c              | 3 +++
>>>>>  drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ---
>>>>>  drivers/gpu/drm/ttm/ttm_bo_vm.c        | 7 +++++++
>>>>>  include/drm/drm_gem.h                  | 4 +++-
>>>>>  4 files changed, 13 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
>>>>> index 56f42e0f2584..2f2b889096b0 100644
>>>>> --- a/drivers/gpu/drm/drm_gem.c
>>>>> +++ b/drivers/gpu/drm/drm_gem.c
>>>>> @@ -1106,6 +1106,9 @@ int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,
>>>>>  		return -EINVAL;
>>>>>  
>>>>>  	if (obj->funcs && obj->funcs->mmap) {
>>>>> +		/* Remove the fake offset */
>>>>> +		vma->vm_pgoff -= drm_vma_node_start(&obj->vma_node);
>>>>> +
>>>>>  		ret = obj->funcs->mmap(obj, vma);
>>>>>  		if (ret)
>>>>>  			return ret;
>>>>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>>>> index a878c787b867..e8061c64c480 100644
>>>>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
>>>>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
>>>>> @@ -542,9 +542,6 @@ int drm_gem_shmem_mmap(struct drm_gem_object *obj, struct vm_area_struct *vma)
>>>>>  	vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot);
>>>>>  	vma->vm_ops = &drm_gem_shmem_vm_ops;
>>>>>  
>>>>> -	/* Remove the fake offset */
>>>>> -	vma->vm_pgoff -= drm_vma_node_start(&shmem->base.vma_node);
>>>>> -
>>>>>  	return 0;
>>>>>  }
>>>>>  EXPORT_SYMBOL_GPL(drm_gem_shmem_mmap);
>>>>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>> index 1a9db691f954..08902c7290a5 100644
>>>>> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
>>>>> @@ -482,6 +482,13 @@ EXPORT_SYMBOL(ttm_bo_mmap);
>>>>>  int ttm_bo_mmap_obj(struct vm_area_struct *vma, struct ttm_buffer_object *bo)
>>>>>  {
>>>>>  	ttm_bo_get(bo);
>>>>> +
>>>>> +	/*
>>>>> +	 * FIXME: &drm_gem_object_funcs.mmap is called with the fake offset
>>>>> +	 * removed. Add it back here until the rest of TTM works without it.
>>>>> +	 */
>>>>> +	vma->vm_pgoff += drm_vma_node_start(&bo->base.vma_node);
>>>>> +
>>>>>  	ttm_bo_mmap_vma_setup(bo, vma);
>>>>>  	return 0;
>>>>>  }
>>>>> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
>>>>> index e71f75a2ab57..c56cbb3509e0 100644
>>>>> --- a/include/drm/drm_gem.h
>>>>> +++ b/include/drm/drm_gem.h
>>>>> @@ -159,7 +159,9 @@ struct drm_gem_object_funcs {
>>>>>  	 *
>>>>>  	 * The callback is used by by both drm_gem_mmap_obj() and
>>>>>  	 * drm_gem_prime_mmap().  When @mmap is present @vm_ops is not
>>>>> -	 * used, the @mmap callback must set vma->vm_ops instead.
>>>>> +	 * used, the @mmap callback must set vma->vm_ops instead. The @mmap
>>>>> +	 * callback is always called with a 0 offset. The caller will remove
>>>>> +	 * the fake offset as necessary.
>>>>>  	 *
>>>>
>>>> Maybe remove this empty comment line here while at it. With that
>>>>
>>>> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>>>>
>>>> I think I'll follow up with a patch to annotate drm_gem_mmap_obj as
>>>> deprecated and that instead this here should be used.
>>>> -Daniel
>>>>
>>>>>  	 */
>>>>>  	int (*mmap)(struct drm_gem_object *obj, struct vm_area_struct *vma);
>>>>> -- 
>>>>> 2.20.1
>>>>>
>>>>
>>>> -- 
>>>> Daniel Vetter
>>>> Software Engineer, Intel Corporation
>>>> http://blog.ffwll.ch
>>>
>>
>> -- 
>> Thomas Zimmermann
>> Graphics Driver Developer
>> SUSE Software Solutions Germany GmbH
>> Maxfeldstr. 5, 90409 Nürnberg, Germany
>> (HRB 36809, AG Nürnberg)
>> Geschäftsführer: Felix Imendörffer
>>
> 
> 
> 
> 

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  reply	other threads:[~2019-11-12  9:49 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-24 19:18 [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap Rob Herring
2019-10-25  5:34 ` Gerd Hoffmann
2019-10-25  7:30 ` Daniel Vetter
2019-11-08 16:27   ` Daniel Vetter
2019-11-08 16:55     ` Daniel Vetter
2019-11-12  8:52       ` Gerd Hoffmann
2019-11-12  9:35         ` Daniel Vetter
2019-11-12 15:37           ` Rob Herring
2019-11-12 19:06             ` Daniel Vetter
2019-11-12 21:31               ` Rob Herring
2019-11-12 22:14                 ` Daniel Vetter
2019-11-13  7:53                   ` Gerd Hoffmann
2019-11-12  9:26     ` Thomas Zimmermann
2019-11-12  9:32       ` Daniel Vetter
2019-11-12  9:49         ` Thomas Zimmermann [this message]
2019-11-12 10:38           ` Gerd Hoffmann
2019-11-12 14:44             ` Daniel Vetter
2019-11-13  7:39               ` Gerd Hoffmann
2019-11-13  8:17                 ` Daniel Vetter
2019-11-13 13:51                   ` Gerd Hoffmann
2019-11-13 16:27                     ` Daniel Vetter
2019-11-15  9:37                       ` Gerd Hoffmann
2019-11-15 10:18                         ` Daniel Vetter
2019-11-15 10:56                           ` Gerd Hoffmann
2019-11-15 15:31                             ` Daniel Vetter
2019-11-18 10:40                               ` Gerd Hoffmann
2019-11-18 16:49                                 ` Daniel Vetter
2019-11-20  8:05                                   ` Gerd Hoffmann
2019-11-20 10:39                                     ` Daniel Vetter
2019-11-20 11:40                                       ` Gerd Hoffmann
2019-11-20 12:04                                         ` Daniel Vetter
2019-11-20 12:18                                           ` Gerd Hoffmann
2019-11-20 12:34                                             ` Daniel Vetter
2019-11-20 13:08                                               ` Gerd Hoffmann
2019-11-20 13:40                                                 ` Daniel Vetter
2019-11-21  8:10                                                   ` Gerd Hoffmann
2019-11-21  8:47                                                     ` Daniel Vetter
2019-11-21  8:02                                   ` Gerd Hoffmann
2019-11-21  8:49                                     ` Daniel Vetter
2019-11-21 10:18                                       ` Gerd Hoffmann
2019-11-21 10:36                                         ` Daniel Vetter
2019-11-13 13:53                   ` Rob Herring
2019-11-13 16:28                     ` Daniel Vetter

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=06f1f400-2e20-5c40-c0ea-967f1ab2b787@suse.de \
    --to=tzimmermann@suse.de \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=kraxel@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 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.