Re: [PATCH] x86/xen: silence smatch warning in pmu_msr_chk_emulated()

[Juergen Gross <jgross@suse.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 1583 bytes --]

On 20.10.22 16:22, Boris Ostrovsky wrote:
> 
> 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.

I didn't test it myself, so I can only speculate.

I guess the problem is when is_intel_pmu_msr() returns true.

In the end I don't think we expect much code churn in this area in the future.
Its not as if the pmu handling for PV guests is expected to be extended.


Juergen

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 3149 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]