On Wed, Jan 17, 2018 at 12:39 AM, Daniel Vetter <daniel@xxxxxxxx> wrote:
On Tue, Jan 16, 2018 at 04:35:59PM -0800, Gurchetan Singh wrote:
> This is required to use buffers allocated by vgem on AMD and ARM devices.
> We're experiencing a case where eviction of the cache races with userspace
> writes. To fix this, flush the cache after retrieving a page.
>
> Signed-off-by: Gurchetan Singh <gurchetansingh@xxxxxxxxxxxx>
> ---
> drivers/gpu/drm/vgem/vgem_drv.c | 1 + Uh ... what exactly are you doing?
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_ drv.c
> index 35bfdfb746a7..fb263969f02d 100644
> --- a/drivers/gpu/drm/vgem/vgem_drv.c
> +++ b/drivers/gpu/drm/vgem/vgem_drv.c
> @@ -112,6 +112,7 @@ static int vgem_gem_fault(struct vm_fault *vmf)
> break;
> }
>
> + drm_flush_pages(obj->base.dev->dev, &page, 1);
Asking because the entire "who's responsible for coherency" story is
entirely undefined still when doing buffer sharing :-/ What is clear is
that currently vgem entirely ignores this (there's not
begin/end_cpu_access callback), mostly because the shared dma-buf support
in drm_prime.c also entirely ignores this.
This patch isn't trying to address the case of a dma-buf imported into vgem. It's trying to address the case when a buffer is created by vgem_gem_dumb_create, mapped by vgem_gem_dumb_map and then accessed by user space. Since the page retrieved by shmem_read_mapping_page during the page fault may still be in the cache, we're experiencing incorrect data in buffer. Here's the test case we're running:
It fails on line 210 on AMD and ARM devices (not Intel though).
And doing a one-time only
flushing in your fault handler is definitely not going to fix this (at
least not if you do anything else than one-shot uploads).
There used to be a be vgem_gem_get_pages function, but that's been removed. I don't know where else to flush in this situation.
-Daniel
> }
> return ret;
> }
> --
> 2.13.5
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
