All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Khatri, Sunil" <sukhatri@amd.com>
To: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>,
	Sunil Khatri <sunil.khatri@amd.com>,
	dri-devel@lists.freedesktop.org, amd-gfx@lists.freedesktop.org
Cc: "Alex Deucher" <alexander.deucher@amd.com>,
	"Christian König" <christian.koenig@amd.com>,
	"Pierre-Eric Pelloux-Prayer" <pierre-eric.pelloux-prayer@amd.com>
Subject: Re: [PATCH v3 1/4] drm: add function drm_file_err to print proc information too
Date: Wed, 16 Apr 2025 14:09:27 +0530	[thread overview]
Message-ID: <2047d128-5c3a-4f9f-a55d-3188fe7ea3c3@amd.com> (raw)
In-Reply-To: <830a2b61-8965-4193-98de-d462a641737f@igalia.com>


On 4/16/2025 12:37 PM, Tvrtko Ursulin wrote:
>
> On 15/04/2025 19:43, Sunil Khatri wrote:
>> Add a drm helper function which get the process information for
>> the drm_file and append the process information using the existing
>> drm_err.
>>
>> Signed-off-by: Sunil Khatri <sunil.khatri@amd.com>
>> ---
>>   include/drm/drm_file.h | 40 ++++++++++++++++++++++++++++++++++++++++
>>   1 file changed, 40 insertions(+)
>>
>> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
>> index 94d365b22505..e329299a2b2c 100644
>> --- a/include/drm/drm_file.h
>> +++ b/include/drm/drm_file.h
>> @@ -37,6 +37,7 @@
>>   #include <uapi/drm/drm.h>
>>     #include <drm/drm_prime.h>
>> +#include <drm/drm_print.h>
>>     struct dma_fence;
>>   struct drm_file;
>> @@ -446,6 +447,45 @@ static inline bool drm_is_accel_client(const 
>> struct drm_file *file_priv)
>>       return file_priv->minor->type == DRM_MINOR_ACCEL;
>>   }
>>   +/**
>> + * drm_file_err - Fill info string with process name and pid
>> + * @file_priv: context of interest for process name and pid
>> + * @fmt: prinf() like format string
>> + *
>> + * This update the user provided buffer with process
>> + * name and pid information for @file_priv
>> + */
>> +__printf(2, 3)
>> +static inline void drm_file_err(struct drm_file *file_priv, const 
>> char *fmt, ...)
>> +{
>> +    struct task_struct *task;
>> +    struct pid *pid;
>> +    struct drm_device *dev = file_priv->minor->dev;
>> +    char new_fmt[256];
>> +    char final_fmt[512];
>> +    va_list args;
>> +
>> +    mutex_lock(&file_priv->client_name_lock);
>> +    rcu_read_lock();
>> +    pid = rcu_dereference(file_priv->pid);
>> +    task = pid_task(pid, PIDTYPE_TGID);
>> +
>> +    if (drm_WARN_ON_ONCE(dev, !task))
>> +        return;
>> +
>> +    snprintf(new_fmt, sizeof(new_fmt), "proc:%s pid:%d 
>> client_name:%s %s",
>> +        task->comm, task->pid, file_priv->client_name ?: "Unset", fmt);
>> +
>> +    va_start(args, fmt);
>> +    vsnprintf(final_fmt, sizeof(final_fmt), new_fmt, args);
>> +
>> +    drm_err(dev, "%s", final_fmt);
>> +    va_end(args);
>> +
>> +    rcu_read_unlock();
>> +    mutex_unlock(&file_priv->client_name_lock);
>> +}
>> +
>
> I was hoping something primitive could be enough. With no temporary 
> stack space required. Primitive on the level of (but simplified for 
> illustration purpose):
>
> #define some_err(_file, _fmt, ...) \
>     drm_err(dev, "client-%s: " _fmt, (_this)->client_name, ##__VA_ARGS__)
I also thought of doing it similarly but that dint work. There was lot 
of code to get the process name and pid along with client_name too. So 
##__VA_ARGS__ dont work as soon as its a function and not macro.
Also drm_err gave me errors and this is the way i find it not 
complaining. new_fmt is a string directly anymore and hence need to %s 
to pass but then the drm_err complain too many args for args to pass. So 
i have to combine new_fmt and args in one to get final_fmt and atleast 
functionally it worked.

Yesterday even i though that i would be as simple as adding a macro.
>
> Am I missing something or that would work?
>
> Regards,
>
> Tvrtko
>
>>   void drm_file_update_pid(struct drm_file *);
>>     struct drm_minor *drm_minor_acquire(struct xarray *minors_xa, 
>> unsigned int minor_id);
>

  reply	other threads:[~2025-04-16  8:39 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-15 18:43 [PATCH v3 1/4] drm: add function drm_file_err to print proc information too Sunil Khatri
2025-04-15 18:43 ` [PATCH v3 2/4] drm/amdgpu: add drm_file reference in userq_mgr Sunil Khatri
2025-04-16  7:29   ` Tvrtko Ursulin
2025-04-16  8:42     ` Khatri, Sunil
2025-04-15 18:43 ` [PATCH v3 3/4] drm/amdgpu: use drm_file_err in logging to also dump process information Sunil Khatri
2025-04-16  7:26   ` Tvrtko Ursulin
2025-04-16 10:01     ` Khatri, Sunil
2025-04-16 12:07       ` Pierre-Eric Pelloux-Prayer
2025-04-16 12:16         ` Khatri, Sunil
2025-04-15 18:43 ` [PATCH v3 4/4] drm/amdgpu: change DRM_ERROR to drm_file_err in amdgpu_userqueue.c Sunil Khatri
2025-04-16  7:18   ` Tvrtko Ursulin
2025-04-16  7:22     ` Khatri, Sunil
2025-04-16  7:07 ` [PATCH v3 1/4] drm: add function drm_file_err to print proc information too Tvrtko Ursulin
2025-04-16  8:39   ` Khatri, Sunil [this message]
2025-04-16 11:22     ` Christian König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2047d128-5c3a-4f9f-a55d-3188fe7ea3c3@amd.com \
    --to=sukhatri@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=pierre-eric.pelloux-prayer@amd.com \
    --cc=sunil.khatri@amd.com \
    --cc=tvrtko.ursulin@igalia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.