Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues: - [High] The error path unconditionally returns ERR_PTR(-ENOMEM), masking the actual error code from vmw_bo_create(). -- commit 97833dd848667c1ef6ccc7587272c584beab9fb5 Author: Dan Carpenter <[email protected]> drm/vmwgfx: Fix NULL vs error pointer bug in vmw_prime_import_sg_table() The patch changes the initial value of gem in vmw_prime_import_sg_table() from NULL to ERR_PTR(-ENOMEM) to prevent a NULL pointer dereference in the caller when vmw_bo_create() fails. > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c > b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c > index 39f8c46550c27..f25db04f87778 100644 > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c > @@ -184,7 +184,7 @@ struct drm_gem_object *vmw_prime_import_sg_table(struct > drm_device *dev, > { > int ret; > struct vmw_private *dev_priv = vmw_priv(dev); > - struct drm_gem_object *gem = NULL; > + struct drm_gem_object *gem = ERR_PTR(-ENOMEM); [Severity: High] This is a pre-existing issue, but does hardcoding ERR_PTR(-ENOMEM) mask the actual error returned by vmw_bo_create()? When vmw_bo_create() fails, it returns an error code in the ret variable: ret = vmw_bo_create(dev_priv, ¶ms, &vbo); if (ret != 0) goto out_no_bo; Since gem is initialized to ERR_PTR(-ENOMEM) and never updated with ret before jumping to out_no_bo, the actual error code is permanently lost. If vmw_bo_create() is interrupted by a signal and returns -ERESTARTSYS, masking it with -ENOMEM breaks the kernel's signal handling and syscall restart mechanism. This could potentially cause unexpected failures in userspace applications and compositors. Could gem be updated to ERR_PTR(ret) in the error path instead? > struct vmw_bo *vbo; > struct vmw_bo_params params = { > .domain = (dev_priv->has_mob) ? VMW_BO_DOMAIN_SYS : > VMW_BO_DOMAIN_VRAM, -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
