Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <2c36799c-af38-fed5-3f31-a8bde25368d7@redhat.com>
Date:   Tue, 11 Oct 2022 15:02:28 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.1
Subject: Re: [kbuild] arch/x86/kvm/x86.c:4988 kvm_arch_tsc_set_attr() warn:
 check for integer overflow 'offset'
Content-Language: en-US
To:     Sean Christopherson <seanjc@google.com>,
        Dan Carpenter <dan.carpenter@oracle.com>
Cc:     kbuild@lists.01.org, Oliver Upton <oupton@google.com>,
        lkp@intel.com, kbuild-all@lists.01.org,
        linux-kernel@vger.kernel.org
References: <202210102159.8nYEC0Hl-lkp@intel.com>
 <Y0Rm/Y5flhd734NX@google.com>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <Y0Rm/Y5flhd734NX@google.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 10/10/22 20:39, Sean Christopherson wrote:
>> 828ca89628bfcb Oliver Upton 2021-09-16 @4988  		tsc = kvm_scale_tsc(vcpu, rdtsc(), vcpu->arch.l1_tsc_scaling_ratio) + offset;
>>
>> Smatch hates obvious user triggerable integer overflows...  No checking
>> on offset.
>
> This is ok, and even necessary, e.g. if the host TSC > guest TSC.

(which in fact is the common case).  Also this is unsigned which is fine 
according to the C standard, though I understand that static analyzers 
want to be stricter.

> Is there anything
> we can do in KVM to help Smatch avoid false positives?  Or do you/Smatch already
> maintain a list of known false positives?

Seconded.

Paolo