On Mon, 24 Jul 2023 13:26:10 +0200
Boris Brezillon <boris.brezil...@collabora.com> wrote:
> The dma-buf backend is supposed to provide its own vm_ops, but some
> implementation just have nothing special to do and leave vm_ops
> untouched, probably expecting this field to be zero initialized (this
> is the case with the system_heap implementation for instance).
> Let's reset vma->vm_ops to NULL to keep things working with these
> implementations.
>
> Fixes: 26d3ac3cb04d ("drm/shmem-helpers: Redirect mmap for imported dma-buf")
> Cc: <sta...@vger.kernel.org>
> Cc: Daniel Vetter <daniel.vet...@ffwll.ch>
> Reported-by: Roman Stratiienko <roman.stratiie...@globallogic.com>
> Signed-off-by: Boris Brezillon <boris.brezil...@collabora.com>
Queued to drm-misc-fixes.
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 4ea6507a77e5..baaf0e0feb06 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -623,7 +623,13 @@ int drm_gem_shmem_mmap(struct drm_gem_shmem_object
> *shmem, struct vm_area_struct
> int ret;
>
> if (obj->import_attach) {
> + /* Reset both vm_ops and vm_private_data, so we don't end up
> with
> + * vm_ops pointing to our implementation if the dma-buf backend
> + * doesn't set those fields.
> + */
> vma->vm_private_data = NULL;
> + vma->vm_ops = NULL;
> +
> ret = dma_buf_mmap(obj->dma_buf, vma, 0);
>
> /* Drop the reference drm_gem_mmap_obj() acquired.*/
