From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Rob Clark <robdclark@gmail.com>, dri-devel@lists.freedesktop.org
Cc: freedreno@lists.freedesktop.org,
"Daniel Vetter" <daniel@ffwll.ch>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
"Christopher Healy" <healych@amazon.com>,
"Emil Velikov" <emil.l.velikov@gmail.com>,
"Christian König" <christian.koenig@amd.com>,
"Rob Clark" <robdclark@chromium.org>,
"David Airlie" <airlied@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 8/9] drm/fdinfo: Add comm/cmdline override fields
Date: Fri, 28 Apr 2023 12:05:35 +0100 [thread overview]
Message-ID: <135ff649-e50c-50f4-55ba-a1b615865e02@linux.intel.com> (raw)
In-Reply-To: <20230427175340.1280952-9-robdclark@gmail.com>
On 27/04/2023 18:53, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
>
> These are useful in particular for VM scenarios where the process which
> has opened to drm device file is just a proxy for the real user in a VM
> guest.
>
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> ---
> Documentation/gpu/drm-usage-stats.rst | 18 ++++++++++++++++++
> drivers/gpu/drm/drm_file.c | 15 +++++++++++++++
> include/drm/drm_file.h | 19 +++++++++++++++++++
> 3 files changed, 52 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
> index 58dc0d3f8c58..e4877cf8089c 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -73,6 +73,24 @@ scope of each device, in which case `drm-pdev` shall be present as well.
> Userspace should make sure to not double account any usage statistics by using
> the above described criteria in order to associate data to individual clients.
>
> +- drm-comm-override: <valstr>
> +
> +Returns the client executable override string. Some drivers support letting
> +userspace override this in cases where the userspace is simply a "proxy".
> +Such as is the case with virglrenderer drm native context, where the host
> +process is just forwarding command submission, etc, from guest userspace.
> +This allows the proxy to make visible the executable name of the actual
> +app in the VM guest.
> +
> +- drm-cmdline-override: <valstr>
> +
> +Returns the client cmdline override string. Some drivers support letting
> +userspace override this in cases where the userspace is simply a "proxy".
> +Such as is the case with virglrenderer drm native context, where the host
> +process is just forwarding command submission, etc, from guest userspace.
> +This allows the proxy to make visible the cmdline of the actual app in the
> +VM guest.
Perhaps it would be okay to save space here by not repeating the
description, like:
drm-comm-override: <valstr>
drm-cmdline-override: <valstr>
Long description blah blah...
This allows the proxy to make visible the _executable name *and* command
line_ blah blah..
> +
> Utilization
> ^^^^^^^^^^^
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 9321eb0bf020..d7514c313af1 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -178,6 +178,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
> spin_lock_init(&file->master_lookup_lock);
> mutex_init(&file->event_read_lock);
>
> + mutex_init(&file->override_lock);
> +
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_open(dev, file);
>
> @@ -292,6 +294,8 @@ void drm_file_free(struct drm_file *file)
> WARN_ON(!list_empty(&file->event_list));
>
> put_pid(file->pid);
> + kfree(file->override_comm);
> + kfree(file->override_cmdline);
> kfree(file);
> }
>
> @@ -995,6 +999,17 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
> PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
> }
>
> + mutex_lock(&file->override_lock);
You could add a fast unlocked check before taking the mutex for no risk
apart a transient false negative. For 99.9999% of userspace it would
mean no pointless lock/unlock cycle.
> + if (file->override_comm) {
> + drm_printf(&p, "drm-comm-override:\t%s\n",
> + file->override_comm);
> + }
> + if (file->override_cmdline) {
> + drm_printf(&p, "drm-cmdline-override:\t%s\n",
> + file->override_cmdline);
> + }
> + mutex_unlock(&file->override_lock);
> +
> if (dev->driver->show_fdinfo)
> dev->driver->show_fdinfo(&p, file);
> }
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 1339e925af52..604d05fa6f0c 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -370,6 +370,25 @@ struct drm_file {
> */
> struct drm_prime_file_private prime;
>
> + /**
> + * @comm: Overridden task comm
> + *
> + * Accessed under override_lock
> + */
> + char *override_comm;
> +
> + /**
> + * @cmdline: Overridden task cmdline
> + *
> + * Accessed under override_lock
> + */
> + char *override_cmdline;
> +
> + /**
> + * @override_lock: Serialize access to override_comm and override_cmdline
> + */
> + struct mutex override_lock;
> +
I don't think this should go to drm just yet though. Only one driver can
make use of it so I'd leave it for later and print from msm_show_fdinfo
for now.
Regards,
Tvrtko
> /* private: */
> #if IS_ENABLED(CONFIG_DRM_LEGACY)
> unsigned long lock_count; /* DRI1 legacy lock count */
WARNING: multiple messages have this Message-ID (diff)
From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Rob Clark <robdclark@gmail.com>, dri-devel@lists.freedesktop.org
Cc: "Rob Clark" <robdclark@chromium.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Jonathan Corbet" <corbet@lwn.net>,
"open list:DOCUMENTATION" <linux-doc@vger.kernel.org>,
"Emil Velikov" <emil.l.velikov@gmail.com>,
"Christopher Healy" <healych@amazon.com>,
"open list" <linux-kernel@vger.kernel.org>,
"Boris Brezillon" <boris.brezillon@collabora.com>,
freedreno@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [PATCH v2 8/9] drm/fdinfo: Add comm/cmdline override fields
Date: Fri, 28 Apr 2023 12:05:35 +0100 [thread overview]
Message-ID: <135ff649-e50c-50f4-55ba-a1b615865e02@linux.intel.com> (raw)
In-Reply-To: <20230427175340.1280952-9-robdclark@gmail.com>
On 27/04/2023 18:53, Rob Clark wrote:
> From: Rob Clark <robdclark@chromium.org>
>
> These are useful in particular for VM scenarios where the process which
> has opened to drm device file is just a proxy for the real user in a VM
> guest.
>
> Signed-off-by: Rob Clark <robdclark@chromium.org>
> ---
> Documentation/gpu/drm-usage-stats.rst | 18 ++++++++++++++++++
> drivers/gpu/drm/drm_file.c | 15 +++++++++++++++
> include/drm/drm_file.h | 19 +++++++++++++++++++
> 3 files changed, 52 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
> index 58dc0d3f8c58..e4877cf8089c 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -73,6 +73,24 @@ scope of each device, in which case `drm-pdev` shall be present as well.
> Userspace should make sure to not double account any usage statistics by using
> the above described criteria in order to associate data to individual clients.
>
> +- drm-comm-override: <valstr>
> +
> +Returns the client executable override string. Some drivers support letting
> +userspace override this in cases where the userspace is simply a "proxy".
> +Such as is the case with virglrenderer drm native context, where the host
> +process is just forwarding command submission, etc, from guest userspace.
> +This allows the proxy to make visible the executable name of the actual
> +app in the VM guest.
> +
> +- drm-cmdline-override: <valstr>
> +
> +Returns the client cmdline override string. Some drivers support letting
> +userspace override this in cases where the userspace is simply a "proxy".
> +Such as is the case with virglrenderer drm native context, where the host
> +process is just forwarding command submission, etc, from guest userspace.
> +This allows the proxy to make visible the cmdline of the actual app in the
> +VM guest.
Perhaps it would be okay to save space here by not repeating the
description, like:
drm-comm-override: <valstr>
drm-cmdline-override: <valstr>
Long description blah blah...
This allows the proxy to make visible the _executable name *and* command
line_ blah blah..
> +
> Utilization
> ^^^^^^^^^^^
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 9321eb0bf020..d7514c313af1 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -178,6 +178,8 @@ struct drm_file *drm_file_alloc(struct drm_minor *minor)
> spin_lock_init(&file->master_lookup_lock);
> mutex_init(&file->event_read_lock);
>
> + mutex_init(&file->override_lock);
> +
> if (drm_core_check_feature(dev, DRIVER_GEM))
> drm_gem_open(dev, file);
>
> @@ -292,6 +294,8 @@ void drm_file_free(struct drm_file *file)
> WARN_ON(!list_empty(&file->event_list));
>
> put_pid(file->pid);
> + kfree(file->override_comm);
> + kfree(file->override_cmdline);
> kfree(file);
> }
>
> @@ -995,6 +999,17 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
> PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
> }
>
> + mutex_lock(&file->override_lock);
You could add a fast unlocked check before taking the mutex for no risk
apart a transient false negative. For 99.9999% of userspace it would
mean no pointless lock/unlock cycle.
> + if (file->override_comm) {
> + drm_printf(&p, "drm-comm-override:\t%s\n",
> + file->override_comm);
> + }
> + if (file->override_cmdline) {
> + drm_printf(&p, "drm-cmdline-override:\t%s\n",
> + file->override_cmdline);
> + }
> + mutex_unlock(&file->override_lock);
> +
> if (dev->driver->show_fdinfo)
> dev->driver->show_fdinfo(&p, file);
> }
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 1339e925af52..604d05fa6f0c 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -370,6 +370,25 @@ struct drm_file {
> */
> struct drm_prime_file_private prime;
>
> + /**
> + * @comm: Overridden task comm
> + *
> + * Accessed under override_lock
> + */
> + char *override_comm;
> +
> + /**
> + * @cmdline: Overridden task cmdline
> + *
> + * Accessed under override_lock
> + */
> + char *override_cmdline;
> +
> + /**
> + * @override_lock: Serialize access to override_comm and override_cmdline
> + */
> + struct mutex override_lock;
> +
I don't think this should go to drm just yet though. Only one driver can
make use of it so I'd leave it for later and print from msm_show_fdinfo
for now.
Regards,
Tvrtko
> /* private: */
> #if IS_ENABLED(CONFIG_DRM_LEGACY)
> unsigned long lock_count; /* DRI1 legacy lock count */
next prev parent reply other threads:[~2023-04-28 11:05 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-27 17:53 [PATCH v2 0/9] drm: fdinfo memory stats Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-27 17:53 ` [PATCH v2 1/9] drm/docs: Fix usage stats typos Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-28 8:50 ` Christian König
2023-04-28 8:50 ` Christian König
2023-04-28 14:29 ` Rob Clark
2023-04-28 14:29 ` Rob Clark
2023-04-27 17:53 ` [PATCH v2 2/9] drm: Add common fdinfo helper Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-27 17:53 ` [PATCH v2 3/9] drm/msm: Switch to " Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-27 17:53 ` [PATCH v2 4/9] drm/amdgpu: " Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-27 17:53 ` [PATCH v2 5/9] drm: Add fdinfo memory stats Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-28 10:56 ` Tvrtko Ursulin
2023-04-28 10:56 ` Tvrtko Ursulin
2023-04-28 14:45 ` Rob Clark
2023-04-28 14:45 ` Rob Clark
2023-05-02 8:29 ` Tvrtko Ursulin
2023-05-02 8:29 ` Tvrtko Ursulin
2023-04-27 17:53 ` [PATCH v2 6/9] drm/msm: Add memory stats to fdinfo Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-27 17:53 ` [PATCH v2 7/9] drm/doc: Relax fdinfo string constraints Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-27 17:53 ` [PATCH v2 8/9] drm/fdinfo: Add comm/cmdline override fields Rob Clark
2023-04-27 17:53 ` Rob Clark
2023-04-28 11:05 ` Tvrtko Ursulin [this message]
2023-04-28 11:05 ` Tvrtko Ursulin
2023-05-01 16:58 ` Rob Clark
2023-05-01 16:58 ` Rob Clark
2023-05-02 7:50 ` Tvrtko Ursulin
2023-05-02 7:50 ` Tvrtko Ursulin
2023-05-18 9:43 ` Tvrtko Ursulin
2023-05-18 9:43 ` Tvrtko Ursulin
2023-05-18 16:28 ` Rob Clark
2023-05-18 16:28 ` Rob Clark
2023-04-27 17:53 ` [PATCH v2 9/9] drm/msm: Wire up comm/cmdline override for fdinfo Rob Clark
2023-04-27 17:53 ` Rob Clark
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=135ff649-e50c-50f4-55ba-a1b615865e02@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=airlied@gmail.com \
--cc=boris.brezillon@collabora.com \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
--cc=freedreno@lists.freedesktop.org \
--cc=healych@amazon.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mripard@kernel.org \
--cc=robdclark@chromium.org \
--cc=robdclark@gmail.com \
--cc=tzimmermann@suse.de \
/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.