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);
}
......
}
_______________________________________________
amd-gfx mailing list
amd-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
