From: Yazen Ghannam <yazen.ghannam@amd.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Karan Sanghavi <karansanghvi98@gmail.com>,
Tony Luck <tony.luck@intel.com>,
linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH v3] RAS/AMD/ATL: Fix unintended sign extension issue from coverity
Date: Mon, 16 Dec 2024 10:43:58 -0500 [thread overview]
Message-ID: <20241216154358.GA460991@yaz-khff2.amd.com> (raw)
In-Reply-To: <20241215181557.GBZ18c3QJw8-7HWeSD@fat_crate.local>
On Sun, Dec 15, 2024 at 07:15:57PM +0100, Borislav Petkov wrote:
> On Wed, Dec 11, 2024 at 11:01:13AM -0500, Yazen Ghannam wrote:
> > On Wed, Nov 27, 2024 at 06:23:48PM +0000, Karan Sanghavi wrote:
> > > This error is reported by coverity scan stating as
> > >
> > > CID 1593397: (#1 of 1): Unintended sign extension (SIGN_EXTENSION)
> > > sign_extension: Suspicious implicit sign extension: pc
> > > with type u16 (16 bits, unsigned) is promoted in
> > > pc << bit_shifts.pc to type int (32 bits, signed),
> > > then sign-extended to type unsigned long (64 bits, unsigned).
> > > If pc << bit_shifts.pc is greater than 0x7FFFFFFF,
> > > the upper bits of the result will all be 1.
> > >
> > > Use u32 for bitwise operations to prevent unintentional
> > > sign extension by assigning the u16 value to a u32
> > > variable before performing the bitwise operation to
> > > avoid unintended sign extension and maintain
> > > consistency with the existing code style.
> > >
> > > Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
> > > Signed-off-by: Karan Sanghavi <karansanghvi98@gmail.com>
>
> > Boris, can you please take this patch if no objections?
>
> Lemme see:
>
> bit_shifts.pc = 5 + FIELD_GET(ADDR_SEL_2_CHAN, temp);
>
> #define ADDR_SEL_2_CHAN GENMASK(15, 12)
>
> that register field is 4 bits, so 0xf is the highest value it can contain.
>
> Thus, bit_shifts.pc can have 20 as its max value.
>
> So all that coverity OMG OMG sign-extension overflow above cannot actually
> really happen, can it?
>
> Because pc is promoted to an int, as the text rightfully points out.
>
> Or am I way off here?
>
Right, the warning is highlighting the implicit sign-extension, and it
doesn't seem to be a functional bug.
The 'temp' variable in this function is there to avoid these types of
warnings. But the 'pc' case was missed.
What do you recommend? Should we adjust the code to be more explicit and
avoid the warning? Or just ignore it?
Thanks,
Yazen
next prev parent reply other threads:[~2024-12-16 15:44 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-27 18:23 [PATCH v3] RAS/AMD/ATL: Fix unintended sign extension issue from coverity Karan Sanghavi
2024-12-11 16:01 ` Yazen Ghannam
2024-12-12 14:40 ` Konstantin Ryabitsev
2024-12-15 18:15 ` Borislav Petkov
2024-12-16 15:43 ` Yazen Ghannam [this message]
2024-12-16 17:36 ` Borislav Petkov
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=20241216154358.GA460991@yaz-khff2.amd.com \
--to=yazen.ghannam@amd.com \
--cc=bp@alien8.de \
--cc=karansanghvi98@gmail.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=tony.luck@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