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

[Gerd Hoffmann]

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?

cheers,
  Gerd