AMD-GFX Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <dmitry.osipenko@collabora.com>
To: Pierre-Eric Pelloux-Prayer <pierre-eric@damsy.net>,
	Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>,
	dri-devel@lists.freedesktop.org, christian.koenig@amd.com,
	tursulin@igalia.com, simona.vetter@ffwll.ch, robdclark@gmail.com,
	alexander.deucher@amd.com, amd-gfx@lists.freedesktop.org
Subject: Re: [PATCH v3 1/6] drm: add DRM_SET_NAME ioctl
Date: Mon, 23 Sep 2024 21:09:02 +0300	[thread overview]
Message-ID: <b1544f77-17c3-40ca-a0a5-c061d6528435@collabora.com> (raw)
In-Reply-To: <d27cdff0-0432-4813-9948-752f6145bef7@damsy.net>

On 9/23/24 19:29, Pierre-Eric Pelloux-Prayer wrote:
...
>>> @@ -78,12 +78,13 @@ static int drm_clients_info(struct seq_file *m,
>>> void *data)
>>>       kuid_t uid;
>>>         seq_printf(m,
>>> -           "%20s %5s %3s master a %5s %10s\n",
>>> +           "%20s %5s %3s master a %5s %10s %20s\n",
>>>              "command",
>>>              "tgid",
>>>              "dev",
>>>              "uid",
>>> -           "magic");
>>> +           "magic",
>>> +           "name");
>>>         /* dev->filelist is sorted youngest first, but we want to
>>> present
>>>        * oldest first (i.e. kernel, servers, clients), so walk
>>> backwardss.
>>> @@ -94,19 +95,22 @@ static int drm_clients_info(struct seq_file *m,
>>> void *data)
>>>           struct task_struct *task;
>>>           struct pid *pid;
>>>   +        mutex_lock(&priv->name_lock);
>>>           rcu_read_lock(); /* Locks priv->pid and pid_task()->comm! */
>>>           pid = rcu_dereference(priv->pid);
>>>           task = pid_task(pid, PIDTYPE_TGID);
>>>           uid = task ? __task_cred(task)->euid : GLOBAL_ROOT_UID;
>>> -        seq_printf(m, "%20s %5d %3d   %c    %c %5d %10u\n",
>>> +        seq_printf(m, "%20s %5d %3d   %c    %c %5d %10u %20s\n",
>>>                  task ? task->comm : "<unknown>",
>>>                  pid_vnr(pid),
>>>                  priv->minor->index,
>>>                  is_current_master ? 'y' : 'n',
>>>                  priv->authenticated ? 'y' : 'n',
>>>                  from_kuid_munged(seq_user_ns(m), uid),
>>> -               priv->magic);
>>> +               priv->magic,
>>> +               priv->name ?: "");
>>
>> There should be a default name similar to task->comm, like "<undefined>"
>> when not set. Perhaps also set name to task->comm by default.
> 
> Honestly I don't see much value in printing "<undefined>" or any other
> default value (+ task->comm is already printed above).

For a machine-parsed string in userspace there should be a value,
otherwise it won't be parseable if you'll add another parameter after
the name, AFAICT.

...
>>>   +static int drm_set_name(struct drm_device *dev, void *data,
>>> +            struct drm_file *file_priv)
>>> +{
>>> +    struct drm_set_name *name = data;
>>> +    void __user *user_ptr;
>>> +    char *new_name;
>>> +    size_t i, len;
>>> +
>>> +    if (name->name_len > DRM_NAME_MAX_LEN)
>>> +        return -EINVAL;
>>> +
>>> +    user_ptr = u64_to_user_ptr(name->name);
>>> +
>>> +    new_name = memdup_user_nul(user_ptr, name->name_len);
>>> +    if (IS_ERR(new_name))
>>> +        return PTR_ERR(new_name);
>>> +
>>> +    len = strlen(new_name);
>>
>> strnlen
> 
> memdup_user_nul returns a NUL-terminated string so I don't see much need
> for using strnlen.

Indeed

...
>>>   static int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
>>>   {
>>>       /* ROOT_ONLY is only for CAP_SYS_ADMIN */
>>> @@ -610,6 +656,8 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
>>>       DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD,
>>> drm_prime_handle_to_fd_ioctl, DRM_RENDER_ALLOW),
>>>       DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE,
>>> drm_prime_fd_to_handle_ioctl, DRM_RENDER_ALLOW),
>>>   +    DRM_IOCTL_DEF(DRM_IOCTL_SET_NAME, drm_set_name,
>>> DRM_RENDER_ALLOW),
>>> +
>>>       DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES,
>>> drm_mode_getplane_res, 0),
>>>       DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 0),
>>>       DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc,
>>> DRM_MASTER),
>>> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
>>> index 8c0030c77308..df26eee8f79c 100644
>>> --- a/include/drm/drm_file.h
>>> +++ b/include/drm/drm_file.h
>>> @@ -388,6 +388,15 @@ struct drm_file {
>>>        * Per-file buffer caches used by the PRIME buffer sharing code.
>>>        */
>>>       struct drm_prime_file_private prime;
>>> +
>>> +    /**
>>> +     * @name:
>>> +     *
>>> +     * Userspace-provided name; useful for accounting and debugging.
>>> +     */
>>> +    const char *name;
>>
>> I'd make the "name" string static, i.e. char name[DRM_NAME_MAX_LEN + 1].
>> That will prevent pointer deref troubles and no additional MM code
>> bloating will be needed.
>>
> 
> Sure, I can do that if others prefer this way too.

Note that in the other email I suggested to use strndup_user(), that
will remove the name-length limitation, but then the name var will
remain to be a string pointer. To me best option would be to replicate
how dma_buf_set_name works.

>>> +    /** @name_lock: Protects @name. */
>>> +    struct mutex name_lock;
>>
>> And then this lock isn't strictly needed anymore and can be removed if
>> "name" string is static.
> 
> The locking also prevents concurrent modification.

Right, locking still will be needed

>>>   };
>>>     /**
>>> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
>>> index 16122819edfe..f5e92e4f909b 100644
>>> --- a/include/uapi/drm/drm.h
>>> +++ b/include/uapi/drm/drm.h
>>> @@ -1024,6 +1024,13 @@ struct drm_crtc_queue_sequence {
>>>       __u64 user_data;    /* user data passed to event */
>>>   };
>>>   +#define DRM_NAME_MAX_LEN    64
>>
>> What about 63, to align data size to 64 bytes including the NULL byte.
> 
> Same as "const char *name;" vs "char name[...]": I don't mind updating
> the code as long as there's a consensus.
> 
>>
>>> +struct drm_set_name {
>>
>> drm_set_name sounds very generic, IMO. Maybe drm_context_set_name?
> 
> drm_client_set_name?
> (since other places use client, like drm_clients_info())

drm_client_set_name sounds good

-- 
Best regards,
Dmitry


  reply	other threads:[~2024-09-24 11:50 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-20  9:06 [PATCH v3 0/6] DRM_SET_NAME ioctl Pierre-Eric Pelloux-Prayer
2024-09-20  9:06 ` [PATCH v3 1/6] drm: add " Pierre-Eric Pelloux-Prayer
2024-09-23 10:06   ` Tvrtko Ursulin
2024-09-24  8:22     ` Pierre-Eric Pelloux-Prayer
2024-09-24  8:38       ` Tvrtko Ursulin
2024-09-23 10:28   ` Dmitry Osipenko
2024-09-23 11:03     ` Dmitry Osipenko
2024-09-23 16:29     ` Pierre-Eric Pelloux-Prayer
2024-09-23 18:09       ` Dmitry Osipenko [this message]
2024-09-23 18:18         ` Dmitry Osipenko
2024-09-24 23:28           ` Dmitry Osipenko
2024-09-20  9:06 ` [PATCH v3 2/6] drm: use drm_file name in fdinfo Pierre-Eric Pelloux-Prayer
2024-09-20  9:06 ` [PATCH v3 3/6] drm/amdgpu: delay the use of amdgpu_vm_set_task_info Pierre-Eric Pelloux-Prayer
2024-09-23 10:25   ` Tvrtko Ursulin
2024-09-24  8:23     ` Christian König
2024-09-24  8:43       ` Tvrtko Ursulin
2024-09-24 10:01         ` Pierre-Eric Pelloux-Prayer
2024-09-20  9:06 ` [PATCH v3 4/6] drm/amdgpu: alloc and init vm::task_info from first submit Pierre-Eric Pelloux-Prayer
2024-09-23 10:58   ` Tvrtko Ursulin
2024-09-24  7:21     ` Pierre-Eric Pelloux-Prayer
2024-09-20  9:06 ` [PATCH v3 5/6] drm/amdgpu: make process_name a flexible array Pierre-Eric Pelloux-Prayer
2024-09-20  9:06 ` [PATCH v3 6/6] drm/amdgpu: use drm_file::name in task_info::process_desc Pierre-Eric Pelloux-Prayer
2024-09-20 12:08   ` 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=b1544f77-17c3-40ca-a0a5-c061d6528435@collabora.com \
    --to=dmitry.osipenko@collabora.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=pierre-eric@damsy.net \
    --cc=robdclark@gmail.com \
    --cc=simona.vetter@ffwll.ch \
    --cc=tursulin@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox