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
next prev parent 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