From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Andi Shyti <andi.shyti@linux.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 13:40:07 -0700 [thread overview]
Message-ID: <87jzxde120.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <ZF4H7Q92rVoas3Hb@ashyti-mobl2.lan>
On Fri, 12 May 2023 02:33:33 -0700, Andi Shyti wrote:
>
Hi Andi,
>
> 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.
OK, in v2 I went ahead and did just that (initializing the variable at the
declaration). I was splitting hair too much :/
> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
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 20:40 UTC|newest]
Thread overview: 8+ 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-10 18:36 ` 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
2023-05-12 20:40 ` Dixit, Ashutosh [this message]
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=87jzxde120.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=andi.shyti@linux.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 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.