[PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap

[Daniel Vetter]

On Wed, Nov 13, 2019 at 07:53:56AM -0600, Rob Herring wrote:
> On Wed, Nov 13, 2019 at 2:18 AM Daniel Vetter <daniel at ffwll.ch> wrote:
> >
> > On Wed, Nov 13, 2019 at 8:39 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
> > >
> > >   Hi,
> > >
> > > > > > >> 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.
> > > > >
> > > > > It's not that simple.  Even when not supporting dma-buf export and
> > > > > import it is still possible to create dma-bufs, import them into the
> > > > > same driver (which doesn't actually export+import but just grabs a gem
> > > > > object reference instead) and also to mmap them via prime/dma-buf code
> > > > > path ...
> > >
> > > ... but after looking again I think we are all green here.  Given that
> > > only self-import works we'll only see vram gem objects in the mmap code
> > > path, which should have everything set up correctly.  Same goes for qxl.
> > >
> > > All other ttm drivers still use the old mmap code path, so all green
> > > there too I think.  Also I somehow doubt dma-buf mmap vs. drm mmap ends
> > > up using different f_mapping, ttm code has a WARN_ON in ttm_bo_vm_open()
> > > which would fire should that be the case.
> > >
> > > Do imported dma-bufs hit the drm mmap code path in the first place?
> > > Wouldn't mmap be handled by the exporting driver?
> >
> > drm_gem_dmabuf_mmap -> obj->funcs->mmap -> ttm_bo_mmap_obj
> >
> > And I'm not seeing anyone adjusting vm_file->f_mapping anywhere here at all.
> >
> > Note to hit this you need userspace to
> > - handle2fd on a buffer to create a dma-buf fd
> > - call mmap directly on that dma-buf fd
> 
> That was exactly the vgem IGT test that prompted $subject fix. (With
> vgem modified to use shmem helpers)

See my other mail, this only hits the right mmap paths. For the unmap side
you need even more (and that part is driver dependent, and vgem would need
some debug tricks to expose that for testing).
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch