From: Nathan Chancellor <nathan@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: kernel test robot <lkp@intel.com>,
llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev,
linux-kernel@vger.kernel.org, x86@kernel.org
Subject: Re: [tip:x86/microcode 1/1] arch/x86/kernel/cpu/microcode/amd.c:714:6: warning: variable 'equiv_id' is used uninitialized whenever 'if' condition is false
Date: Tue, 30 Jul 2024 11:32:32 -0700 [thread overview]
Message-ID: <20240730183232.GA2428521@thelio-3990X> (raw)
In-Reply-To: <20240730080326.GAZqieTl1Gz4RheSiI@fat_crate.local>
On Tue, Jul 30, 2024 at 10:03:26AM +0200, Borislav Petkov wrote:
> On Mon, Jul 29, 2024 at 08:30:08AM -0700, Nathan Chancellor wrote:
> > Right, as clang does not perform interprocedural analysis for the sake
> > of warnings. That's partly why GCC's version of this warning was
> > disabled in commit 78a5255ffb6a ("Stop the ad-hoc games with
> > -Wno-maybe-initialized").
>
> So why aren't we shutting up clang too?
Because it does not suffer from the same issues. There are many more
instances of local variables that are genuinely uninitialized when used
that get properly flagged than instances such as this where lack of
interprocedural analysis may cause emission of a false positive. Losing
Clang's version of the warning means that no compiler would warn on
instances of obviously uninitialized local variables, which still occurs
quite frequently.
> > While it may be properly handled now, I think this pattern of
> > conditionally avoiding using a variable uninitialized is dubious.
>
> Well, in this particular case of the microcode loader, this is the best
> compromise I can think of - I have two different paths of handling a microcode
> patch - Zen and newer - and before - so I need those separate flows.
>
> So sometimes it makes sense.
Sure, I just think it is a potential footgun waiting to happen but it's
obviously fine now.
> > So I guess you can just ignore this if you want but others (maybe even
> > Linus) will likely notice this and report it as well.
>
> I think this warning should be behind W=1 if it can trigger false positives.
I disagree, any warning can trigger false positives, as they are
heuristics. Feel free to propose a patch if you feel strongly about it
though and we can bring the discussion to a wider audience.
> Anyway:
>
> From: "Borislav Petkov (AMD)" <bp@alien8.de>
> Date: Tue, 30 Jul 2024 09:52:43 +0200
> Subject: [PATCH] x86/microcode/AMD: Fix a -Wsometimes-uninitialized clang
> false positive
>
> Initialize equiv_id in order to shut up:
>
> arch/x86/kernel/cpu/microcode/amd.c:714:6: warning: variable 'equiv_id' is \
> used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
> if (x86_family(bsp_cpuid_1_eax) < 0x17) {
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> because clang doesn't do interprocedural analysis for warnings to see
> that this variable won't be used uninitialized.
>
> Fixes: 94838d230a6c ("x86/microcode/AMD: Use the family,model,stepping encoded in the patch ID")
> Reported-by: kernel test robot <lkp@intel.com>
> Closes: https://lore.kernel.org/oe-kbuild-all/202407291815.gJBST0P3-lkp@intel.com/
> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
> ---
> arch/x86/kernel/cpu/microcode/amd.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/kernel/cpu/microcode/amd.c b/arch/x86/kernel/cpu/microcode/amd.c
> index 1f5d36f92b8a..f63b051f25a0 100644
> --- a/arch/x86/kernel/cpu/microcode/amd.c
> +++ b/arch/x86/kernel/cpu/microcode/amd.c
> @@ -703,7 +703,7 @@ static struct ucode_patch *find_patch(unsigned int cpu)
> {
> struct ucode_cpu_info *uci = ucode_cpu_info + cpu;
> u32 rev, dummy __always_unused;
> - u16 equiv_id;
> + u16 equiv_id = 0;
>
> /* fetch rev if not populated yet: */
> if (!uci->cpu_sig.rev) {
> --
> 2.43.0
>
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
prev parent reply other threads:[~2024-07-30 18:32 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-29 11:04 kernel test robot
2024-07-29 11:26 ` Borislav Petkov
2024-07-29 15:30 ` Nathan Chancellor
2024-07-29 16:50 ` Borislav Petkov
2024-07-30 1:43 ` Nathan Chancellor
2024-07-30 8:03 ` Borislav Petkov
2024-07-30 18:32 ` Nathan Chancellor [this message]
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=20240730183232.GA2428521@thelio-3990X \
--to=nathan@kernel.org \
--cc=bp@alien8.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=llvm@lists.linux.dev \
--cc=oe-kbuild-all@lists.linux.dev \
--cc=x86@kernel.org \
/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
all inboxes | Powered by JetHome®