All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: dri-devel@lists.freedesktop.org
Cc: "Christian König" <christian.koenig@amd.com>,
	"Tvrtko Ursulin" <tvrtko.ursulin@intel.com>
Subject: [RFC 0/3] File owner follows use
Date: Wed, 30 Nov 2022 13:34:04 +0000	[thread overview]
Message-ID: <20221130133407.2689864-1-tvrtko.ursulin@linux.intel.com> (raw)

From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>

Not so long ago when I sent out my DRM cgroup controller RFC I had some pieces
in it which were tracking the real client using a specific drm_file. Christian
then suggested that should probably be extracted and improved in the DRM core
from the start, which was on his wishlist for a long period. So this mini-series
is an attempt at that.

First patch is just a logging cleanup, 2nd probably makes sense on it's own
since it replaces tracking thread names with progresses which are more
meaningful. Third one is where action is.

The benefit on it's own is rather small, especially relative to the complication
to track it, where it essentially changes the debugfs clients output from:

             command   pid dev master a   uid      magic
                Xorg  1744   0   y    y     0          0
                Xorg  1744   0   n    y     0          1
                Xorg  1744   0   n    y     0          2
                Xorg  1744   0   n    y     0          3

To something like:

             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

One ugly part is one synchronise_rcu() on the first (hopefully) only fd
handover. The latency of that could be improved by further wrapping and
kfree_rcu() if desired.

Another part I am unsure of is whether master nodes are ever handed over via
sockets. I assumed no and exluded them from ownership updates. If they need to
be then drm_master_check_perm() would break, I think. So looking for some
feedback in this area please.

Tvrtko Ursulin (3):
  drm: Replace DRM_DEBUG with drm_dbg_core in file and ioctl handling
  drm: Track clients by tgid and not tid
  drm: Update file owner during use

 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c |  6 ++-
 drivers/gpu/drm/drm_auth.c              |  3 +-
 drivers/gpu/drm/drm_debugfs.c           | 12 +++---
 drivers/gpu/drm/drm_file.c              | 53 ++++++++++++++++++++-----
 drivers/gpu/drm/drm_ioc32.c             | 13 +++---
 drivers/gpu/drm/drm_ioctl.c             | 28 +++++++------
 drivers/gpu/drm/nouveau/nouveau_drm.c   |  5 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_gem.c     |  6 ++-
 include/drm/drm_file.h                  | 13 +++++-
 9 files changed, 97 insertions(+), 42 deletions(-)

-- 
2.34.1


             reply	other threads:[~2022-11-30 13:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-30 13:34 Tvrtko Ursulin [this message]
2022-11-30 13:34 ` [RFC 1/3] drm: Replace DRM_DEBUG with drm_dbg_core in file and ioctl handling Tvrtko Ursulin
2022-12-02  8:38   ` Christian König
2022-11-30 13:34 ` [RFC 2/3] drm: Track clients by tgid and not tid Tvrtko Ursulin
2022-11-30 13:34 ` [RFC 3/3] drm: Update file owner during use Tvrtko Ursulin
2022-11-30 14:18   ` Daniel Vetter
2022-12-01 11:09     ` Tvrtko Ursulin
2022-12-02  9:01       ` Christian König
2023-01-05 12:32         ` Daniel Vetter
2023-01-06 10:32           ` Christian König
2023-01-06 10:53             ` Daniel Vetter
2023-01-06 14:53               ` Christian König
2023-01-06 18:00                 ` Daniel Vetter
2023-01-10 13:14                   ` Tvrtko Ursulin
2023-01-11 22:19                     ` Daniel Vetter
2023-01-12 18:49                       ` Tvrtko Ursulin
2023-01-06 13:18           ` Tvrtko Ursulin
2022-12-01  2:32   ` kernel test robot
2022-12-01 14:39   ` kernel test robot
2022-12-02 10:42   ` kernel test robot

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=20221130133407.2689864-1-tvrtko.ursulin@linux.intel.com \
    --to=tvrtko.ursulin@linux.intel.com \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=tvrtko.ursulin@intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.