Intel-XE Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Summers, Stuart" <stuart.summers@intel.com>
To: "sashiko-reviews@lists.linux.dev"
	<sashiko-reviews@lists.linux.dev>,
	"Vivi, Rodrigo" <rodrigo.vivi@intel.com>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>
Subject: Re: [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters
Date: Thu, 20 Aug 2026 21:08:43 +0000	[thread overview]
Message-ID: <7a4c189b484d937b6924aabe0c0a588464eabe17.camel@intel.com> (raw)
In-Reply-To: <20260820201956.0A36F1F000E9@smtp.kernel.org>

On Thu, 2026-08-20 at 20:19 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> - [Low] Global namespace pollution from generic attribute names
> --
> 
> --- Patch [8]: [PATCH 08/10] drm/xe: Add infrastructure for debug
> configfs parameters ---
> commit c6663e692904c84b3875225b65be4210162f1f5e
> Author: Stuart Summers <stuart.summers@intel.com>
> 
> drm/xe: Add infrastructure for debug configfs parameters
> 
> This commit introduces an X-macro pattern for defining debug configfs
> parameters
> in the Xe driver. It automatically generates backing structs,
> configuration
> attributes, and accessors from a single parameter list to simplify
> adding new
> debug entries.
> 
> > diff --git a/drivers/gpu/drm/xe/xe_configfs_debug_params.c
> > b/drivers/gpu/drm/xe/xe_configfs_debug_params.c
> > new file mode 100644
> > index 0000000000000..00e5ff175c0af
> > --- /dev/null
> > +++ b/drivers/gpu/drm/xe/xe_configfs_debug_params.c
> 
> [ ... ]
> 
> > +/*
> > + * Define the configfs_attribute objects. These are non-static so
> > they
> > + * can be referenced from xe_configfs_debug.c.
> > + */
> > +#define _XE_PARAM_DEFINE_ATTR(_T, _name, _def, _val, _vis, _get,
> > _fallback) \
> > +struct configfs_attribute attr_##_name =
> > {                              \
> 
> [Severity: Low]
> Could this naming convention cause global symbol collisions? 
> 
> Since these objects are non-static (defined in the global namespace),
> naming 
> them attr_##_name could lead to link-time multiple definition errors
> if another 
> subsystem happens to export a variable with a generic name like
> attr_timeout or 
> attr_enable.
> 
> Would it be safer to use a subsystem-specific prefix, such as 
> xe_configfs_attr_##_name, to prevent namespace pollution?
> 
> > +       .ca_name        =
> > __stringify(_name),                           \
> > +       .ca_owner       =
> > THIS_MODULE,                                  \
> > +       .ca_mode        =
> > 0644,                                         \
> > +       .show           =
> > _name##_show,                                 \
> > +       .store          =
> > _name##_store,                                \
> > +};
> > +
> > +XE_CONFIGFS_DEBUG_PARAMS_FOR_EACH(_XE_PARAM_DEFINE_ATTR)
> 
> [ ... ]
> 
> > diff --git a/drivers/gpu/drm/xe/xe_configfs_debug_params.h
> > b/drivers/gpu/drm/xe/xe_configfs_debug_params.h
> > new file mode 100644
> > index 0000000000000..954ca4343136d
> > --- /dev/null
> > +++ b/drivers/gpu/drm/xe/xe_configfs_debug_params.h
> 
> [ ... ]
> 
> > +/*
> > + * Forward declarations of the per-parameter configfs_attribute
> > objects.
> > + *
> > + * The objects themselves are defined in
> > xe_configfs_debug_params.c (as
> > + * non-static so they can be referenced from xe_configfs_debug.c's
> > + * xe_configfs_debug_attrs[] array and is_visible() callback).
> > They live
> > + * in the same translation unit as the X-macro-generated
> > show/store
> > + * handlers; consumers should reference them via attr_<name>.
> > + */
> > +#define _XE_PARAM_DECLARE_ATTR(_T, _name, _def, _val, _vis, _get,
> > _fallback) \
> > +       extern struct configfs_attribute attr_##_name;
> 
> [Severity: Low]
> Similar to the definition above, this macro exposes attr_##_name in
> the global 
> namespace. Adding a prefix like xe_configfs_attr_##_name here would
> align with 
> the definition change and ensure namespace safety.

The other review comments from Sashiko were all pre-existing issues I'm
not planning on addressing in this series, but I decided to address
these naming suggestions in the latest series..

I still need to update the IGT, but I think otherwise these should be
ready to review.

Thanks,
Stuart

> 
> > +XE_CONFIGFS_DEBUG_PARAMS_FOR_EACH(_XE_PARAM_DECLARE_ATTR)
> > +#undef _XE_PARAM_DECLARE_ATTR
> 


  reply	other threads:[~2026-08-20 21:08 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-20 20:07 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-20 20:07 ` [PATCH 01/10] drm/xe: Guard configfs attribute reads in getters Stuart Summers
2026-08-20 20:19   ` sashiko-bot
2026-08-20 20:07 ` [PATCH 02/10] drm/xe: Sort xe_config_device fields Stuart Summers
2026-08-20 20:20   ` sashiko-bot
2026-08-20 20:07 ` [PATCH 03/10] drm/xe: Split out configfs data structures Stuart Summers
2026-08-20 20:07 ` [PATCH 04/10] drm/xe: Add a new debug focused configfs group Stuart Summers
2026-08-20 20:07 ` [PATCH 05/10] drm/xe: Move debug configfs entries to xe_configfs_debug.c Stuart Summers
2026-08-20 20:20   ` sashiko-bot
2026-08-20 20:07 ` [PATCH 06/10] drm/xe/guc: Add configfs support for guc_log_level Stuart Summers
2026-08-20 20:07 ` [PATCH 07/10] drm/xe/guc: Add support for NPK as a GuC log target Stuart Summers
2026-08-20 20:07 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers
2026-08-20 20:19   ` sashiko-bot
2026-08-20 21:08     ` Summers, Stuart [this message]
2026-08-20 20:07 ` [PATCH 09/10] drm/xe: Migrate existing debug configfs entries to params infrastructure Stuart Summers
2026-08-20 20:07 ` [PATCH 10/10] drm/xe: Taint kernel when debug configfs parameters are set Stuart Summers
2026-08-20 20:14 ` ✗ CI.checkpatch: warning for Add new debug infrastructure for configfs (rev6) Patchwork
2026-08-20 20:16 ` ✓ CI.KUnit: success " Patchwork
2026-08-20 20:54 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-20 22:45 ` ✗ Xe.CI.FULL: failure " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2026-08-20 21:06 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-20 21:06 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers
2026-08-07 19:45 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-07 19:45 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers
2026-08-05 23:20 [PATCH 00/10] Add new debug infrastructure for configfs Stuart Summers
2026-08-05 23:20 ` [PATCH 08/10] drm/xe: Add infrastructure for debug configfs parameters Stuart Summers

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=7a4c189b484d937b6924aabe0c0a588464eabe17.camel@intel.com \
    --to=stuart.summers@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=rodrigo.vivi@intel.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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