From: John Harrison <john.c.harrison@intel.com>
To: Michal Wajdeczko <michal.wajdeczko@intel.com>,
<intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH] drm/xe/guc: Make debugfs guc_log_dmesg attribute write-only
Date: Mon, 9 Jun 2025 15:11:43 -0700 [thread overview]
Message-ID: <6f4f4aff-7e83-4b40-920a-2edafa60b06a@intel.com> (raw)
In-Reply-To: <20250603175302.593-1-michal.wajdeczko@intel.com>
On 6/3/2025 10:53 AM, Michal Wajdeczko wrote:
> Ocassionally we want to dump a GuC log into the dmesg, but current
I would describe this interface as purely a test for the dump-via-dmesg
code itself. It is not really useful for triggering a dump for actual
bug investigation purposes. If a system is alive enough to use this
debugfs interface then it is alive enough to use the official
devcoredump or GuC-log-via-debugfs interfaces.
Having said that, this change probably needs an IGT test to go with it.
One that explicitly does the write and triggers the dump to make sure it
works. Potentially it could actually check the dmesg output for a valid
dump but as a first pass, just calling the interface and ensuring the
kernel doesn't die is a good step!
The problem at the moment is that there are multiple IGTs which do a
blanket read of everything in debugfs. Thus, they get the dump-via-dmesg
even if they aren't interested in it. And those multiple dumps fill up
dmesg to the point where CI complains about too much log output. So
making this change will make those tests more reliable. However, it
means that we would get no testing of the dump-via-dmesg mechanism
itself. So unless a new IGT is added to explicitly test the interface,
we might as well just remove it completely.
> implementation is based on the drm debugfs API and was triggering
> dump on the read operation. Expose guc_log_dmesg attribute as
> write-only using pure debugfs API to make dump requests explicit.
>
> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
> Cc: John Harrison <John.C.Harrison@Intel.com>
> ---
> drivers/gpu/drm/xe/xe_guc_debugfs.c | 43 ++++++++++++++++++++++++-----
> 1 file changed, 36 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/xe/xe_guc_debugfs.c b/drivers/gpu/drm/xe/xe_guc_debugfs.c
> index 0b102ab46c4d..eb6124d02d53 100644
> --- a/drivers/gpu/drm/xe/xe_guc_debugfs.c
> +++ b/drivers/gpu/drm/xe/xe_guc_debugfs.c
> @@ -5,6 +5,8 @@
>
> #include "xe_guc_debugfs.h"
>
> +#include <linux/debugfs.h>
> +
> #include <drm/drm_debugfs.h>
> #include <drm/drm_managed.h>
>
> @@ -85,12 +87,6 @@ static int guc_log(struct xe_guc *guc, struct drm_printer *p)
> return 0;
> }
>
> -static int guc_log_dmesg(struct xe_guc *guc, struct drm_printer *p)
> -{
> - xe_guc_log_print_dmesg(&guc->log);
> - return 0;
> -}
> -
> static int guc_ctb(struct xe_guc *guc, struct drm_printer *p)
> {
> xe_guc_ct_print(&guc->ct, p, true);
> @@ -121,9 +117,39 @@ static const struct drm_info_list slpc_debugfs_list[] = {
> /* everything else should be added here */
> static const struct drm_info_list pf_only_debugfs_list[] = {
> { "guc_log", .show = guc_debugfs_show, .data = guc_log },
> - { "guc_log_dmesg", .show = guc_debugfs_show, .data = guc_log_dmesg },
> };
>
> +/*
> + * /sys/kernel/debug/dri/0/
> + * ├── gt0
> + * │ ├── uc
> + * │ │ ├── guc_log_dmesg
> + */
> +static ssize_t guc_log_dmesg_write(struct file *file,
> + const char __user *userbuf,
> + size_t count, loff_t *ppos)
> +{
> + struct seq_file *s = file->private_data;
> + struct xe_guc *guc = s->private;
> + bool yes;
> + int ret;
> +
> + if (*ppos)
> + return -EINVAL;
> + ret = kstrtobool_from_user(userbuf, count, &yes);
> + if (ret < 0)
> + return ret;
> + if (yes)
> + xe_guc_log_print_dmesg(&guc->log);
> + return count;
> +}
> +
> +static int guc_log_dmesg_show(struct seq_file *s, void *unused)
> +{
> + return 0;
> +}
> +DEFINE_SHOW_STORE_ATTRIBUTE(guc_log_dmesg);
Is a 'show' entry needed if the file is write only?
John.
> +
> void xe_guc_debugfs_register(struct xe_guc *guc, struct dentry *parent)
> {
> struct xe_device *xe = guc_to_xe(guc);
> @@ -142,5 +168,8 @@ void xe_guc_debugfs_register(struct xe_guc *guc, struct dentry *parent)
> drm_debugfs_create_files(slpc_debugfs_list,
> ARRAY_SIZE(slpc_debugfs_list),
> parent, minor);
> +
> + debugfs_create_file("guc_log_dmesg", 0200, parent,
> + guc, &guc_log_dmesg_fops);
> }
> }
next prev parent reply other threads:[~2025-06-09 22:11 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-03 17:53 [PATCH] drm/xe/guc: Make debugfs guc_log_dmesg attribute write-only Michal Wajdeczko
2025-06-03 17:58 ` ✓ CI.Patch_applied: success for " Patchwork
2025-06-03 17:58 ` ✓ CI.checkpatch: " Patchwork
2025-06-03 17:59 ` ✗ CI.KUnit: failure " Patchwork
2025-06-04 19:24 ` ✓ CI.Patch_applied: success for drm/xe/guc: Make debugfs guc_log_dmesg attribute write-only (rev2) Patchwork
2025-06-04 19:24 ` ✓ CI.checkpatch: " Patchwork
2025-06-04 19:25 ` ✓ CI.KUnit: " Patchwork
2025-06-04 19:36 ` ✓ CI.Build: " Patchwork
2025-06-04 19:39 ` ✓ CI.Hooks: " Patchwork
2025-06-04 19:40 ` ✓ CI.checksparse: " Patchwork
2025-06-04 20:42 ` ✓ Xe.CI.BAT: " Patchwork
2025-06-05 18:17 ` ✓ Xe.CI.Full: " Patchwork
2025-06-09 22:11 ` John Harrison [this message]
2025-06-24 20:51 ` [PATCH] drm/xe/guc: Make debugfs guc_log_dmesg attribute write-only Michal Wajdeczko
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=6f4f4aff-7e83-4b40-920a-2edafa60b06a@intel.com \
--to=john.c.harrison@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=michal.wajdeczko@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox