Chris Wilson <[email protected]> writes:

> Update the context.name on closing so that the persistent requests are
> clear in debug prints.
>
> Signed-off-by: Chris Wilson <[email protected]>
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_context.c | 18 ++++++++++++++++++
>  1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index 982770e8163d..72d389afa28a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -461,11 +461,29 @@ static void kill_context(struct i915_gem_context *ctx)
>       }
>  }
>  
> +static void set_closed_name(struct i915_gem_context *ctx)
> +{
> +     char *s;
> +
> +     /* Replace '[]' with '<>' to indicate closed in debug prints */
> +
> +     s = strrchr(ctx->name, '[');
> +     if (!s)
> +             return;
> +
> +     *s = '<';
> +
> +     s = strchr(s + 1, ']');

I can't think of a way for s+1 to be NULL as the TASKCOM_LEN + 8
makes the [pid] appear at the end.

With extending the buffer, one could have gone with 
+= "(closed)". To be more readable.

But would bloat the buffer more.

Which leads to thinking that perhaps we should grab only
the taskname/pid and then construct the name on the fly.

That needs buffer for callers, which might be nontrivial
due to usage on error situations.

So after running a circle,

Reviewed-by: Mika Kuoppala <[email protected]>


> +     if (s)
> +             *s = '>';
> +}
> +
>  static void context_close(struct i915_gem_context *ctx)
>  {
>       struct i915_address_space *vm;
>  
>       i915_gem_context_set_closed(ctx);
> +     set_closed_name(ctx);
>  
>       mutex_lock(&ctx->mutex);
>  
> -- 
> 2.24.0
>
> _______________________________________________
> Intel-gfx mailing list
> [email protected]
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Reply via email to