Re: [Intel-gfx] [PATCH v2] drm: Update file owner during use

2023-09-20 Thread Christian König

Am 20.09.23 um 15:21 schrieb Tvrtko Ursulin:


On 28/08/2023 20:58, Rob Clark wrote:

On Wed, Jun 21, 2023 at 2:48 AM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

With the typical model where the display server opens 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   y    y 0  0
 Xorg  2344   0   n    y 0  2
 Xorg  2344   0   n    y 0  3
 Xorg  2344   0   n    y 0  4

After:

$ cat /sys/kernel/debug/dri/0/clients
  command  tgid dev master a   uid  magic
 Xorg   830   0   y    y 0  0
    xfce4-session   880   0   n    y 0  1
    xfwm4   943   0   n    y 0  2
    neverball  1095   0   n    y 0  3

*)
More detailed and historically accurate description of various handover
implementation kindly provided by Emil Velikov:

"""
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.
"""

v2:
  * Fixed typo in commit text and added a fine historical explanation
    from Emil.

Signed-off-by: Tvrtko Ursulin 
Cc: "Christian König" 
Cc: Daniel Vetter 
Acked-by: Christian König 
Reviewed-by: Emil Velikov 


Reviewed-by: Rob Clark 
Tested-by: Rob Clark 


Thanks. If everyone else is happy with this approach I don't have the 
commit rights for drm-misc.


Going to take care of pushing this.

Regards,
Christian.



Regards,

Tvrtko




---
  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 74055cba3dc9..849097dff02b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -963,6 +963,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;

 /*
@@ -972,8 +973,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))

Re: [Intel-gfx] [PATCH v2] drm: Update file owner during use

2023-09-20 Thread Tvrtko Ursulin



On 28/08/2023 20:58, Rob Clark wrote:

On Wed, Jun 21, 2023 at 2:48 AM Tvrtko Ursulin
 wrote:


From: Tvrtko Ursulin 

With the typical model where the display server opens 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

*)
More detailed and historically accurate description of various handover
implementation kindly provided by Emil Velikov:

"""
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.
"""

v2:
  * Fixed typo in commit text and added a fine historical explanation
from Emil.

Signed-off-by: Tvrtko Ursulin 
Cc: "Christian König" 
Cc: Daniel Vetter 
Acked-by: Christian König 
Reviewed-by: Emil Velikov 


Reviewed-by: Rob Clark 
Tested-by: Rob Clark 


Thanks. If everyone else is happy with this approach I don't have the 
commit rights for drm-misc.


Regards,

Tvrtko




---
  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 74055cba3dc9..849097dff02b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -963,6 +963,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;

 /*
@@ -972,8 +973,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
--- 

Re: [Intel-gfx] [PATCH v2] drm: Update file owner during use

2023-08-28 Thread Rob Clark
On Wed, Jun 21, 2023 at 2:48 AM Tvrtko Ursulin
 wrote:
>
> From: Tvrtko Ursulin 
>
> With the typical model where the display server opens 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
>
> *)
> More detailed and historically accurate description of various handover
> implementation kindly provided by Emil Velikov:
>
> """
> 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.
> """
>
> v2:
>  * Fixed typo in commit text and added a fine historical explanation
>from Emil.
>
> Signed-off-by: Tvrtko Ursulin 
> Cc: "Christian König" 
> Cc: Daniel Vetter 
> Acked-by: Christian König 
> Reviewed-by: Emil Velikov 

Reviewed-by: Rob Clark 
Tested-by: Rob Clark 

> ---
>  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 74055cba3dc9..849097dff02b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -963,6 +963,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;
>
> /*
> @@ -972,8 +973,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 

[Intel-gfx] [PATCH v2] drm: Update file owner during use

2023-06-21 Thread Tvrtko Ursulin
From: Tvrtko Ursulin 

With the typical model where the display server opens 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

*)
More detailed and historically accurate description of various handover
implementation kindly provided by Emil Velikov:

"""
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.
"""

v2:
 * Fixed typo in commit text and added a fine historical explanation
   from Emil.

Signed-off-by: Tvrtko Ursulin 
Cc: "Christian König" 
Cc: Daniel Vetter 
Acked-by: Christian König 
Reviewed-by: Emil Velikov 
---
 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 74055cba3dc9..849097dff02b 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -963,6 +963,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;
 
/*
@@ -972,8 +973,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;