From: "Govindapillai, Vinod" <vinod.govindapillai@intel.com>
To: "sashiko-reviews@lists.linux.dev" <sashiko-reviews@lists.linux.dev>
Cc: "intel-xe@lists.freedesktop.org" <intel-xe@lists.freedesktop.org>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH 3/4] drm/xe/pm: allow the device to signal PME from D3hot
Date: Wed, 2 Sep 2026 06:10:43 +0000 [thread overview]
Message-ID: <bd2fac668a777b3bd87594bcc69e8ac22e00b9fd.camel@intel.com> (raw)
In-Reply-To: <20260826230200.69FF21F000E9@smtp.kernel.org>
On Wed, 2026-08-26 at 23:01 +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
> - [Medium] The variable `err` is used uninitialized in the warning
> message when `pci_enable_wake()` fails, potentially leaking stack
> memory to the kernel log.
> --
>
> commit 49538b2bae6d5a5f0599da227733b24b63d3639b
> Author: Vinod Govindapillai <vinod.govindapillai@intel.com>
>
> drm/xe/pm: allow the device to signal PME from D3hot
>
> Make the device a usable wakeup source so it can raise PME while
> runtime
> suspended to D3hot The PCI core marks endpoints wakeup-capable
> but leaves
> them disabled, so pci_enable_wake() returns -EINVAL until the
> driver opts
> in using devm_device_init_wakeup(). D3cold is excluded, as the
> device
> loses power there and cannot signal at all.
>
> > diff --git a/drivers/gpu/drm/xe/xe_pci.c
> > b/drivers/gpu/drm/xe/xe_pci.c
> > index 3b3b6426d960c..af59859fd8c96 100644
> > --- a/drivers/gpu/drm/xe/xe_pci.c
> > +++ b/drivers/gpu/drm/xe/xe_pci.c
> [ ... ]
> > @@ -1380,6 +1384,7 @@ static int xe_pci_runtime_suspend(struct
> > device *dev)
> > {
> > struct pci_dev *pdev = to_pci_dev(dev);
> > struct xe_device *xe = pdev_to_xe_device(pdev);
> > + bool pme_armed = false;
> > int err;
> >
> > /*
> > @@ -1391,9 +1396,20 @@ static int xe_pci_runtime_suspend(struct
> > device *dev)
> > xe_assert(xe, !IS_SRIOV_VF(xe));
> > xe_assert(xe, !pci_num_vf(pdev));
> >
> > - err = xe_pm_runtime_suspend(xe, false);
> > - if (err)
> > + if (xe_pm_pme_capable(xe)) {
> > + pme_armed = !pci_enable_wake(pdev, PCI_D3hot,
> > true);
> > + if (!pme_armed)
> > + drm_warn(&xe->drm,
> > + "Failed to arm PME for D3hot:
> > %d\n", err);
>
> [Severity: Medium]
> Could this leak uninitialized stack memory to the kernel log? It
> looks like
> the variable err is used in the warning message when
> pci_enable_wake() fails
> in xe_pci_runtime_suspend(), but it hasn't been initialized yet.
> Since the
> return value from pci_enable_wake() is inverted into the boolean
> pme_armed,
> the actual error code is never captured in err before printing it.
>
Yes. This need to fixed. Will fix this in the next iteration
BR
Vinod
next prev parent reply other threads:[~2026-09-02 6:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-26 22:53 [PATCH 0/4] PM_PME support on display hotplug Vinod Govindapillai
2026-08-26 22:53 ` [PATCH 1/4] drm/i915/hpd: plumb keep_hpd through irq reset Vinod Govindapillai
2026-08-26 23:08 ` sashiko-bot
2026-08-26 22:53 ` [PATCH 2/4] drm/xe/pm: plumb PME capability to runtime suspend handler Vinod Govindapillai
2026-08-26 23:04 ` sashiko-bot
2026-08-26 22:53 ` [PATCH 3/4] drm/xe/pm: allow the device to signal PME from D3hot Vinod Govindapillai
2026-08-26 23:01 ` sashiko-bot
2026-09-02 6:10 ` Govindapillai, Vinod [this message]
2026-08-26 22:53 ` [PATCH 4/4] drm/i915/display: Avoid HPD polling if the device is PME capable Vinod Govindapillai
2026-08-26 23:02 ` ✓ CI.KUnit: success for pm_pme support on display hotplug (rev2) Patchwork
2026-08-26 23:38 ` ✓ Xe.CI.BAT: " Patchwork
2026-08-27 0:08 ` ✓ i915.CI.BAT: " Patchwork
2026-08-27 2:02 ` ✓ Xe.CI.FULL: " Patchwork
2026-08-27 7:29 ` ✗ i915.CI.Full: failure " Patchwork
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=bd2fac668a777b3bd87594bcc69e8ac22e00b9fd.camel@intel.com \
--to=vinod.govindapillai@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--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 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.