Re: [RFC 02/10] drm: Update file owner during use
Hi Tvrtko Sorry for the delay, real life and other obligations got in the way. On Thu, 8 Jun 2023 at 15:26, Tvrtko Ursulin wrote: > On 21/04/2023 13:13, Emil Velikov wrote: > Are you okay if I just paste your very fine explanation verbatim, with > credits? > Yes, feel free to use as much of if as you see reasonable. > > I also had a brief look at 01/10, although I cannot find many > > references for the pid <> tguid mappings. Be that on the kernel side > > or userspace - do you have any links that I can educate myself? > > TGID or thread group leader. For single threaded userspace TGID equals > to PID, while for multi-threaded first thread TGID equals PID/TID, while > additional threads PID/TID does not equal TGID. Clear, as mud? :) My > POSIX book is misplaced somewhere having not consulted it years... :) > Ack. /me looks into actually buying one, perhaps Thanks Emil
Re: [RFC 02/10] drm: Update file owner during use
On 21/04/2023 13:13, Emil Velikov wrote: Greetings everyone, Above all - hell yeah. Thank you Tvrtko, this has been annoying the hell out of me for ages. Yay! On Tue, 14 Mar 2023 at 14:19, Tvrtko Ursulin wrote: From: Tvrtko Ursulin With the typical model where the display server opends the file descriptor and then hands it over to the client we were showing stale data in debugfs. s/opends/opens/ Thanks! But as a whole the sentence is fairly misleading. Story time: The traditional model, the server was the orchestrator managing the primary device node. From the fd, to the master status and authentication. But looking at the fd alone, this has varied across the years. IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open fd(s) and reuse those whenever needed, DRI2 the client was responsible for open() themselves and with DRI3 the fd was passed to the client. Around the inception of DRI3 and systemd-logind, the latter became another possible orchestrator. Whereby Xorg and Wayland compositors could ask it for the fd. For various reasons (hysterical and genuine ones) Xorg has a fallback path going the open(), whereas Wayland compositors are moving to solely relying on logind... some never had fallback even. Over the past few years, more projects have emerged which provide functionality similar (be that on API level, Dbus, or otherwise) to systemd-logind. Apart from that, the commit is spot on. I like the use of rcu and the was_master handling is correct. With some message polish this commit is: Reviewed-by: Emil Velikov Are you okay if I just paste your very fine explanation verbatim, with credits? I also had a brief look at 01/10, although I cannot find many references for the pid <> tguid mappings. Be that on the kernel side or userspace - do you have any links that I can educate myself? TGID or thread group leader. For single threaded userspace TGID equals to PID, while for multi-threaded first thread TGID equals PID/TID, while additional threads PID/TID does not equal TGID. Clear, as mud? :) My POSIX book is misplaced somewhere having not consulted it years... :) Regards, Tvrtko
Re: [RFC 02/10] drm: Update file owner during use
Greetings everyone, Above all - hell yeah. Thank you Tvrtko, this has been annoying the hell out of me for ages. On Tue, 14 Mar 2023 at 14:19, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > With the typical model where the display server opends the file descriptor > and then hands it over to the client we were showing stale data in > debugfs. s/opends/opens/ But as a whole the sentence is fairly misleading. Story time: The traditional model, the server was the orchestrator managing the primary device node. From the fd, to the master status and authentication. But looking at the fd alone, this has varied across the years. IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open fd(s) and reuse those whenever needed, DRI2 the client was responsible for open() themselves and with DRI3 the fd was passed to the client. Around the inception of DRI3 and systemd-logind, the latter became another possible orchestrator. Whereby Xorg and Wayland compositors could ask it for the fd. For various reasons (hysterical and genuine ones) Xorg has a fallback path going the open(), whereas Wayland compositors are moving to solely relying on logind... some never had fallback even. Over the past few years, more projects have emerged which provide functionality similar (be that on API level, Dbus, or otherwise) to systemd-logind. Apart from that, the commit is spot on. I like the use of rcu and the was_master handling is correct. With some message polish this commit is: Reviewed-by: Emil Velikov I also had a brief look at 01/10, although I cannot find many references for the pid <> tguid mappings. Be that on the kernel side or userspace - do you have any links that I can educate myself? Thanks Emil
Re: [RFC 02/10] drm: Update file owner during use
Am 14.03.23 um 15:18 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
With the typical model where the display server opends the file descriptor
and then hands it over to the client we were showing stale data in
debugfs.
Fix it by updating the drm_file->pid on ioctl access from a different
process.
The field is also made RCU protected to allow for lockless readers. Update
side is protected with dev->filelist_mutex.
Before:
$ cat /sys/kernel/debug/dri/0/clients
command pid dev master a uid magic
Xorg 2344 0 yy 0 0
Xorg 2344 0 ny 0 2
Xorg 2344 0 ny 0 3
Xorg 2344 0 ny 0 4
After:
$ cat /sys/kernel/debug/dri/0/clients
command tgid dev master a uid magic
Xorg 830 0 yy 0 0
xfce4-session 880 0 ny 0 1
xfwm4 943 0 ny 0 2
neverball 1095 0 ny 0 3
Signed-off-by: Tvrtko Ursulin
Cc: "Christian König"
Cc: Daniel Vetter
Looks completely correct to me, but I can't claim that I understand all
those nasty details around drm_master handling.
So only Acked-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++--
drivers/gpu/drm/drm_auth.c | 3 +-
drivers/gpu/drm/drm_debugfs.c | 10 ---
drivers/gpu/drm/drm_file.c | 40 +++--
drivers/gpu/drm/drm_ioctl.c | 3 ++
drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 6 ++--
include/drm/drm_file.h | 13 ++--
8 files changed, 71 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 863cb668e000..67ce634992f6 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -960,6 +960,7 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file *m,
void *unused)
list_for_each_entry(file, >filelist, lhead) {
struct task_struct *task;
struct drm_gem_object *gobj;
+ struct pid *pid;
int id;
/*
@@ -969,8 +970,9 @@ 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_TGID);
- seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid),
+ pid = rcu_dereference(file->pid);
+ task = pid_task(pid, PIDTYPE_TGID);
+ seq_printf(m, "pid %8d command %s:\n", pid_nr(pid),
task ? task->comm : "");
rcu_read_unlock();
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index cf92a9ae8034..2ed2585ded37 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -235,7 +235,8 @@ static int drm_new_set_master(struct drm_device *dev,
struct drm_file *fpriv)
static int
drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
{
- if (file_priv->pid == task_pid(current) && file_priv->was_master)
+ if (file_priv->was_master &&
+ rcu_access_pointer(file_priv->pid) == task_pid(current))
return 0;
if (!capable(CAP_SYS_ADMIN))
diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 4855230ba2c6..b46f5ceb24c6 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -90,15 +90,17 @@ static int drm_clients_info(struct seq_file *m, void *data)
*/
mutex_lock(>filelist_mutex);
list_for_each_entry_reverse(priv, >filelist, lhead) {
- struct task_struct *task;
bool is_current_master = drm_is_current_master(priv);
+ struct task_struct *task;
+ struct pid *pid;
- rcu_read_lock(); /* locks pid_task()->comm */
- task = pid_task(priv->pid, PIDTYPE_TGID);
+ 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",
task ? task->comm : "",
- pid_vnr(priv->pid),
+ pid_vnr(pid),
priv->minor->index,
is_current_master ? 'y' : 'n',
priv->authenticated ? 'y' : 'n',
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index c1018c470047..f2f8175ece15 100644
