drivers: gpu: drm: is it a memleak in function radeon_user_framebuffer_create

[Christian König]

Good catch, yes that error handling seems to leak the buffer handle in 
this case.

Feel free to provide a patch to fix this and CC me.

Regards,
Christian.

Am 20.04.20 um 09:37 schrieb 亿一:
> Hi, all:
>      When reviewing function radeon_user_framebuffer_create,  what if
> obj->import_attach is not NULL, it return directly without release obj
> reference holded in function drm_gem_object_lookup.
> it is a memleak of obj.
> static struct drm_framebuffer *
> radeon_user_framebuffer_create(struct drm_device *dev,
>         struct drm_file *file_priv,
>         const struct drm_mode_fb_cmd2 *mode_cmd)
>      {
>          struct drm_gem_object *obj;
>          struct drm_framebuffer *fb;
>          int ret;
>
>          obj = drm_gem_object_lookup(file_priv, mode_cmd->handles[0]);
>          if (obj ==  NULL) {
>              dev_err(&dev->pdev->dev, "No GEM object associated to
> handle 0x%08X, "
>                            "can't create framebuffer\n", mode_cmd->handles[0]);
>          return ERR_PTR(-ENOENT);
>          }
>
>          /* Handle is imported dma-buf, so cannot be migrated to VRAM
> for scanout */
>          if (obj->import_attach) {
>              DRM_DEBUG_KMS("Cannot create framebuffer from imported dma_buf\n");
>              return ERR_PTR(-EINVAL);
>          }
>
>          fb = kzalloc(sizeof(*fb), GFP_KERNEL);
>          if (fb == NULL) {
>              drm_gem_object_put_unlocked(obj);
>              return ERR_PTR(-ENOMEM);
>          }
>
>      ......
>
>      }