Messages in this thread | | | Date | Thu, 20 Oct 2022 10:22:17 -0400 | Subject | Re: [PATCH] x86/xen: silence smatch warning in pmu_msr_chk_emulated() | From | Boris Ostrovsky <> |
| |
On 10/20/22 9:34 AM, Juergen Gross wrote: > On 20.10.22 15:16, Jan Beulich wrote: >> On 20.10.2022 13:37, Juergen Gross wrote: >>> Commit 8714f7bcd3c2 ("xen/pv: add fault recovery control to pmu msr >>> accesses") introduced code resulting in a warning issued by the smatch >>> static checker, claiming to use an uninitialized variable. >>> >>> This is a false positive, but work around the warning nevertheless. >> >> The risk of introducing a problem might be quite low here, but in general >> it exists: With the adjustment you remove any chance of the compiler >> spotting a missing initialization before use. And I'm not convinced using >> 0 in such a case would actually be ending up sufficiently benign. > > Hmm, an alternative would be to initialize it to -1 and add a test for the > index to be >= 0 before using it. > > Or to live with the smash warning with the chance, that a compiler might be > warning for the same reason in the future.
Is smatch complaining about both variables or just index? There are two cases in is_intel_pmu_msr() where it returns true but index is not set so perhaps that's what bothers smatch? It shold not complain if is_intel_pmu_msr() returns false.
-boris
| |