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

From: Gerd Hoffmann <kraxel@redhat.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel <dri-devel@lists.freedesktop.org>,
	Thomas Zimmermann <tzimmermann@suse.de>
Subject: Re: [PATCH v2] drm/gem: Fix mmap fake offset handling for drm_gem_object_funcs.mmap
Date: Fri, 15 Nov 2019 10:37:38 +0100	[thread overview]
Message-ID: <20191115093738.kdi4qopah6hvntrb@sirius.home.kraxel.org> (raw)
In-Reply-To: <20191113162729.GQ23790@phenom.ffwll.local>

> You need memory pressure, to force ttm to unmap the bo, not userspace. So
> roughly
> 1. create bo
> 2. mmap it through drm fd, write some stuff
> 3. export to dma-buf, mmap it, verify stuff is there
> 4. create a pile more bo, mmap them write to them
> 5. once you've thrashed all of vram enough, recheck your original bo. If
> I'm right you should get the following:
>    - drm fd mmap still show right content
>    - dma-buf fd mmap shows random crap that you've written into other
>      buffers
> 
> Ofc you need to make sure that an mmap actually forces the buffer into
> vram. So might need a combo of modeset+mmap, to make that happen. Plain
> mmap might just give you ptes that point into system memory, which is not
> managed by ttm like vram.

Is any move buffer good enough to trigger this, i.e. will SYSTEM -> VRAM
work too?  That'll be easier because all I need to do is map the buffer
to a crtc to force pinning to vram, then check if the mappings are
intact still ...

cheers,
  Gerd

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