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

[Daniel Vetter]

On Thu, Nov 21, 2019 at 11:18 AM Gerd Hoffmann <kraxel at redhat.com> wrote:
>
> On Thu, Nov 21, 2019 at 09:49:53AM +0100, Daniel Vetter wrote:
> > On Thu, Nov 21, 2019 at 09:02:59AM +0100, Gerd Hoffmann wrote:
> > >   Hi,
> > >
> > > > > update-object-after-move works fine.
> > > > >
> > > > > try zap mappings with madvise(dontneed) has no bad effects (after vram
> > > > > move, trying to force re-creating the ptes).
> > > >
> > > > Well if it's broken the zapping wouldn't work :-)
> > > >
> > > > > didn't try the memory pressure thing yet.
> > > >
> > > > I'm surprised ... and I have no idea how/why it keeps working.
> > > >
> > > > For my paranoia, can you instrument the ttm page fault handler, and double
> > > > check that we get new faults after the move, and set up new ptes for the
> > > > same old mapping, but now pointing at the new place in vram?
> > >
> > > Hmm, only the drm device mapping is faulted in after moving it,
> > > the dma-buf mapping is not.  Fixed by:
> >
> > Ah yes, that's more what I'd expect to happen, and the below is what I'd
> > expect to fix things up. I think we should move it up ahead of the device
> > callback (so that drivers can overwrite) and then push as a fix. Separate
> > from a possible patch to undo the fake offset removal.
> > -Daniel
>
> Is there a more elegant way than copying the intel list on non-intel
> patches to kick intel ci?

Nope, not really.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch