Hi Nirmoy,
On Friday, 10 March 2023 15:11:38 CET Nirmoy Das wrote:
> debug_active_activate() expected ref->count to be zero
> which is not true anymore as __i915_active_activate() calls
> debug_active_activate() after incrementing the count.
>
> Fixes: 04240e30ed06 ("drm/i915: Skip taking acquire mutex for no ref->active
callback")
> Cc: Chris Wilson <[email protected]>
> Cc: Tvrtko Ursulin <[email protected]>
> Cc: Thomas Hellström <[email protected]>
> Cc: Andi Shyti <[email protected]>
> Cc: [email protected]
> Cc: <[email protected]> # v5.10+
> Signed-off-by: Nirmoy Das <[email protected]>
> ---
> drivers/gpu/drm/i915/i915_active.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/
i915_active.c
> index a9fea115f2d2..1c3066eb359a 100644
> --- a/drivers/gpu/drm/i915/i915_active.c
> +++ b/drivers/gpu/drm/i915/i915_active.c
> @@ -92,7 +92,7 @@ static void debug_active_init(struct i915_active *ref)
> static void debug_active_activate(struct i915_active *ref)
> {
> lockdep_assert_held(&ref->tree_lock);
> - if (!atomic_read(&ref->count)) /* before the first inc */
> + if (atomic_read(&ref->count) == 1) /* after the first inc */
While that's obviously better than never calling debug_active_activate(), I'm
wondering how likely we can still miss it because the counter being
incremented, e.g. via i915_active_acquire_if_busy(), by a concurrent thread.
Since __i915_active_activate() is the only user and its decision making step
is serialized against itself with a spinlock, couldn't we better call
debug_object_activate() unconditionally here?
Thanks,
Janusz
> debug_object_activate(ref, &active_debug_desc);
> }
>
>
