Re: [PATCH 01/10] drm/exec: Add helper to bypass IGNORE_DUPLICATES flag

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] drm_exec_lock_obj_report_dup() incorrectly passes `false` for `always_report_duplicates`, defeating its purpose and leading to premature lock releases.
--

commit ac725923453fdf4ef4b9421f9c3993a995b946f9
Author: Natalie Vock <natalie.vock@gmx.de>

drm/exec: Add helper to bypass IGNORE_DUPLICATES flag

This commit introduces a new helper, drm_exec_lock_obj_report_dup(), which
is intended to bypass the DRM_EXEC_IGNORE_DUPLICATES flag during a single
locking operation. This enables callers like the TTM LRU eviction walk to
determine if an object was already locked by an outer context.

> diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
> --- a/drivers/gpu/drm/drm_exec.c
> +++ b/drivers/gpu/drm/drm_exec.c

[ ... ]

> +/**
> + * drm_exec_lock_obj_report_dup - lock a GEM object for use, but always report duplicates
> + * @exec: the drm_exec object with the state
> + * @obj: the GEM object to lock
> + *
> + * Like drm_exec_lock_obj, lock a GEM object for use and grab a reference to it.
> + * Unlike drm_exec_lock_obj, DRM_EXEC_IGNORE_DUPLICATES is ignored and duplicates are
> + * always reported.
> + *
> + * Returns: -EDEADLK if a contention is detected, -EALREADY when object is
> + * already locked, -ENOMEM when memory allocation failed and zero for success.
> + */
> +int drm_exec_lock_obj_report_dup(struct drm_exec *exec,
> +				 struct drm_gem_object *obj)
> +{
> +	return __drm_exec_lock_obj(exec, obj, false);

[Severity: Critical]
Should this pass true for the always_report_duplicates parameter instead of
false?

By passing false, this helper behaves identically to drm_exec_lock_obj() and
will not bypass the DRM_EXEC_IGNORE_DUPLICATES flag. If it incorrectly
returns 0 instead of -EALREADY when an object is already locked, could an
LRU walk assume it acquired the lock and subsequently call
drm_exec_unlock_obj()?

This sequence appears to lead to a premature lock release and dropped GEM
reference while the outer context still relies on them, potentially causing
a use-after-free during GPU memory eviction.

> +}
> +EXPORT_SYMBOL(drm_exec_lock_obj_report_dup);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260703-ttm_2_drm_exec-v1-0-43685ac1286b@gmx.de?part=1