From: Andi Shyti <andi.shyti@linux.intel.com>
To: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
Cc: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
Rodrigo Vivi <rodrigo.vivi@intel.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning
Date: Fri, 12 May 2023 11:33:33 +0200 [thread overview]
Message-ID: <ZF4H7Q92rVoas3Hb@ashyti-mobl2.lan> (raw)
In-Reply-To: <87y1luepbx.wl-ashutosh.dixit@intel.com>
Hi Ashutosh,
On Thu, May 11, 2023 at 10:43:30AM -0700, Dixit, Ashutosh wrote:
> On Wed, 10 May 2023 11:36:06 -0700, Ashutosh Dixit wrote:
> >
> > Loading i915 on UBSAN enabled kernels (CONFIG_UBSAN/CONFIG_UBSAN_BOOL)
> > causes the following warning:
> >
> > UBSAN: invalid-load in drivers/gpu/drm/i915/gt/uc/intel_uc.c:558:2
> > load of value 255 is not a valid value for type '_Bool'
> > Call Trace:
> > dump_stack_lvl+0x57/0x7d
> > ubsan_epilogue+0x5/0x40
> > __ubsan_handle_load_invalid_value.cold+0x43/0x48
> > __uc_init_hw+0x76a/0x903 [i915]
> > ...
> > i915_driver_probe+0xfb1/0x1eb0 [i915]
> > i915_pci_probe+0xbe/0x2d0 [i915]
> >
> > The warning happens because during probe i915_hwmon is still not available
> > which results in the output boolean variable *old remaining
> > uninitialized.
>
> Note that the variable was uninitialized in this case but it was never used
> uninitialized (the variable was not needed when it was uninitialized). So
> there was no bug in the code. UBSAN warning is just complaining about the
> uninitialized variable being passed into a function (where it is not used).
>
> Also the variable can be initialized in the caller (__uc_init_hw) too and
> it will fix this issue. However in __uc_init_hw the assumption is that the
> variable will be initialized in the callee (i915_hwmon_power_max_disable),
> so that is how I have done it in this patch.
>
> I thought these clarifications will help with the review.
I think we should not just consider what's now but also what can
come later. The use of pl1en is not 100% future proof and
therefore your patch, even though now is not fixing anything,
might avoid wrong uses in the future.
I'm just wondering, though, why not initializing the variable at
it's declaration. As you wish.
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Andi
> Thanks.
> --
> Ashutosh
>
> > Silence the warning by initializing the variable to an arbitrary value.
> >
> > Signed-off-by: Ashutosh Dixit <ashutosh.dixit@intel.com>
> > ---
> > drivers/gpu/drm/i915/i915_hwmon.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c b/drivers/gpu/drm/i915/i915_hwmon.c
> > index a3bdd9f68a458..685663861bc0b 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -502,8 +502,11 @@ void i915_hwmon_power_max_disable(struct drm_i915_private *i915, bool *old)
> > struct i915_hwmon *hwmon = i915->hwmon;
> > u32 r;
> >
> > - if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit))
> > + if (!hwmon || !i915_mmio_reg_valid(hwmon->rg.pkg_rapl_limit)) {
> > + /* Fix uninitialized bool variable warning */
> > + *old = false;
> > return;
> > + }
> >
> > mutex_lock(&hwmon->hwmon_lock);
> >
> > --
> > 2.38.0
> >
next prev parent reply other threads:[~2023-05-12 9:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 18:36 [Intel-gfx] [PATCH] drm/i915/hwmon: Silence UBSAN uninitialized bool variable warning Ashutosh Dixit
2023-05-11 0:20 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2023-05-11 3:56 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-05-11 17:43 ` [Intel-gfx] [PATCH] " Dixit, Ashutosh
2023-05-12 9:33 ` Andi Shyti [this message]
2023-05-12 20:40 ` Dixit, Ashutosh
2023-05-12 9:41 ` Andrzej Hajda
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=ZF4H7Q92rVoas3Hb@ashyti-mobl2.lan \
--to=andi.shyti@linux.intel.com \
--cc=ashutosh.dixit@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=rodrigo.vivi@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