From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Cc: "Rob Clark" <robdclark@chromium.org>,
Kenny.Ho@amd.com, "Daniel Vetter" <daniel.vetter@ffwll.ch>,
"Johannes Weiner" <hannes@cmpxchg.org>,
linux-kernel@vger.kernel.org,
"Stéphane Marchesin" <marcheu@chromium.org>,
"Christian König" <christian.koenig@amd.com>,
"Alex Deucher" <alexander.deucher@amd.com>,
linux-graphics-maintainer@vmware.com,
"Zefan Li" <lizefan.x@bytedance.com>,
"Dave Airlie" <airlied@redhat.com>, "Tejun Heo" <tj@kernel.org>,
cgroups@vger.kernel.org, "T . J . Mercier" <tjmercier@google.com>,
"Zack Rusin" <zackr@vmware.com>
Subject: [RFC 01/10] drm: Track clients by tgid and not tid
Date: Tue, 14 Mar 2023 14:18:55 +0000 [thread overview]
Message-ID: <20230314141904.1210824-2-tvrtko.ursulin@linux.intel.com> (raw)
In-Reply-To: <20230314141904.1210824-1-tvrtko.ursulin@linux.intel.com>
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Thread group id (aka pid from userspace point of view) is a more
interesting thing to show as an owner of a DRM fd, so track and show that
instead of the thread id.
In the next patch we will make the owner updated post file descriptor
handover, which will also be tgid based to avoid ping-pong when multiple
threads access the fd.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zack Rusin <zackr@vmware.com>
Cc: linux-graphics-maintainer@vmware.com
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: "Christian König" <christian.koenig@amd.com>
Reviewed-by: Zack Rusin <zackr@vmware.com>
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 2 +-
drivers/gpu/drm/drm_debugfs.c | 4 ++--
drivers/gpu/drm/drm_file.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index d8e683688daa..863cb668e000 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -969,7 +969,7 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file *m, void *unused)
* Therefore, we need to protect this ->comm access using RCU.
*/
rcu_read_lock();
- task = pid_task(file->pid, PIDTYPE_PID);
+ task = pid_task(file->pid, PIDTYPE_TGID);
seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid),
task ? task->comm : "<unknown>");
rcu_read_unlock();
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4f643a490dc3..4855230ba2c6 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -80,7 +80,7 @@ static int drm_clients_info(struct seq_file *m, void *data)
seq_printf(m,
"%20s %5s %3s master a %5s %10s\n",
"command",
- "pid",
+ "tgid",
"dev",
"uid",
"magic");
@@ -94,7 +94,7 @@ static int drm_clients_info(struct seq_file *m, void *data)
bool is_current_master = drm_is_current_master(priv);
rcu_read_lock(); /* locks pid_task()->comm */
- task = pid_task(priv->pid, PIDTYPE_PID);
+ task = pid_task(priv->pid, PIDTYPE_TGID);
uid = task ? __task_cred(task)->euid : GLOBAL_ROOT_UID;
seq_printf(m, "%20s %5d %3d %c %c %5d %10u\n",
task ? task->comm : "<unknown>",
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index a51ff8cee049..c1018c470047 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -156,7 +156,7 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
if (!file)
return ERR_PTR(-ENOMEM);
- file->pid = get_pid(task_pid(current));
+ file->pid = get_pid(task_tgid(current));
file->minor = minor;
/* for compatibility root is always authenticated */
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
index d6baf73a6458..c0da89e16e6f 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_gem.c
@@ -241,7 +241,7 @@ static int vmw_debugfs_gem_info_show(struct seq_file *m, void *unused)
* Therefore, we need to protect this ->comm access using RCU.
*/
rcu_read_lock();
- task = pid_task(file->pid, PIDTYPE_PID);
+ task = pid_task(file->pid, PIDTYPE_TGID);
seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid),
task ? task->comm : "<unknown>");
rcu_read_unlock();
--
2.37.2
next prev parent reply other threads:[~2023-03-14 14:18 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 14:18 [RFC v4 00/10] DRM scheduling cgroup controller Tvrtko Ursulin
2023-03-14 14:18 ` Tvrtko Ursulin [this message]
2023-03-14 15:33 ` [RFC 01/10] drm: Track clients by tgid and not tid Christian König
2023-03-15 9:52 ` Tvrtko Ursulin
2023-03-15 13:19 ` Christian König
2023-03-14 14:18 ` [RFC 02/10] drm: Update file owner during use Tvrtko Ursulin
2023-03-14 15:49 ` Christian König
[not found] ` <20230314141904.1210824-3-tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-04-21 12:13 ` Emil Velikov
2023-06-08 14:26 ` Tvrtko Ursulin
2023-06-20 14:48 ` Emil Velikov
2023-03-14 14:18 ` [RFC 03/10] cgroup: Add the DRM cgroup controller Tvrtko Ursulin
2023-03-14 14:18 ` [RFC 04/10] drm/cgroup: Track DRM clients per cgroup Tvrtko Ursulin
2023-03-14 14:18 ` [RFC 05/10] drm/cgroup: Add ability to query drm cgroup GPU time Tvrtko Ursulin
2023-03-14 14:19 ` [RFC 06/10] drm/cgroup: Add over budget signalling callback Tvrtko Ursulin
2023-03-14 14:19 ` [RFC 07/10] drm/cgroup: Only track clients which are providing drm_cgroup_ops Tvrtko Ursulin
2023-03-14 14:19 ` [RFC 08/10] cgroup/drm: Introduce weight based drm cgroup control Tvrtko Ursulin
2023-03-14 14:19 ` [RFC 09/10] drm/i915: Wire up with drm controller GPU time query Tvrtko Ursulin
2023-03-14 14:19 ` [RFC 10/10] drm/i915: Implement cgroup controller over budget throttling Tvrtko Ursulin
[not found] ` <20230314141904.1210824-1-tvrtko.ursulin-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2023-03-25 1:43 ` [RFC v4 00/10] DRM scheduling cgroup controller Tejun Heo
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=20230314141904.1210824-2-tvrtko.ursulin@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=Intel-gfx@lists.freedesktop.org \
--cc=Kenny.Ho@amd.com \
--cc=airlied@redhat.com \
--cc=alexander.deucher@amd.com \
--cc=cgroups@vger.kernel.org \
--cc=christian.koenig@amd.com \
--cc=daniel.vetter@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=hannes@cmpxchg.org \
--cc=linux-graphics-maintainer@vmware.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=marcheu@chromium.org \
--cc=robdclark@chromium.org \
--cc=tj@kernel.org \
--cc=tjmercier@google.com \
--cc=zackr@vmware.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