From: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: "xen-devel@lists.xenproject.org" <xen-devel@lists.xenproject.org>
Subject: Re: New Defects reported by Coverity Scan for XenProject
Date: Mon, 8 Sep 2025 14:48:55 +0200 [thread overview]
Message-ID: <DCNFIZNXYSZS.2SXOS2FXVOS4Z@amd.com> (raw)
In-Reply-To: <9e474109-7aa1-42b9-9fa6-31c4ef0fb856@suse.com>
On Mon Sep 8, 2025 at 1:25 PM CEST, Jan Beulich wrote:
> On 08.09.2025 13:04, Alejandro Vallejo wrote:
>> On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote:
>>> On 07.09.2025 16:37, scan-admin@coverity.com wrote:
>>>> ** CID 1665362: Integer handling issues (INTEGER_OVERFLOW)
>>>> /xen/lib/find-next-bit.c: 104 in find_next_zero_bit()
>>>>
>>>>
>>>> _____________________________________________________________________________________________
>>>> *** CID 1665362: Integer handling issues (INTEGER_OVERFLOW)
>>>> /xen/lib/find-next-bit.c: 104 in find_next_zero_bit()
>>>> 98 }
>>>> 99 if (!size)
>>>> 100 return result;
>>>> 101 tmp = *p;
>>>> 102
>>>> 103 found_first:
>>>>>>> CID 1665362: Integer handling issues (INTEGER_OVERFLOW)
>>>>>>> Expression "0xffffffffffffffffUL << size", where "size" is known to be equal to 63, overflows the type of "0xffffffffffffffffUL << size", which is type "unsigned long".
>>>> 104 tmp |= ~0UL << size;
>>>> 105 if (tmp == ~0UL) /* Are any bits zero? */
>>>> 106 return result + size; /* Nope. */
>>>> 107 found_middle:
>>>> 108 return result + ffz(tmp);
>>>> 109 }
>>>
>>> I cannot make sense of their claim. 0xffffffffffffffffUL << 63 is simply
>>> 0x8000000000000000UL, isn't it? Where's the overflow there? There also
>>> cannot be talk of a 32-bit build, or else ~0UL would have been transformed
>>> to 0xffffffffUL.
>>
>> The offending line LGTM too.
>>
>> The only credible explanation I can think of is Coverity flagging discarded 1s
>> on left shifts as loss of precision.
>>
>> If so, "~((1 << size) - 1)", or "(~0UL >> size) << size" should make it happy,
>> but surely that error would flare up with all uses of GENMASK() too?
>
> And with any other non-zero values of "size" here.
>
> Jan
Is this the only issue flagged? Or are there any others of the same kind? It
might me easier to spot a pattern with a larger dataset.
Cheers,
Alejandro
next prev parent reply other threads:[~2025-09-08 12:49 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <68bd98b92c2b2_2afba52d9ed55e79908873e@prd-scan-dashboard-0.mail>
2025-09-08 10:19 ` New Defects reported by Coverity Scan for XenProject Jan Beulich
2025-09-08 11:04 ` Alejandro Vallejo
2025-09-08 11:25 ` Jan Beulich
2025-09-08 12:48 ` Alejandro Vallejo [this message]
2025-09-08 13:17 ` Jan Beulich
[not found] <6922db67d5bee_ec6942e9307a67994398e5@prd-scan-dashboard-0.mail>
2025-11-24 8:37 ` Jan Beulich
[not found] <68b9a73be8eb_27ea7e2d9ed55e799088716@prd-scan-dashboard-0.mail>
2025-09-04 14:54 ` Jan Beulich
[not found] <67f26722e020c_13a342abaf9ddd9a0513e7@prd-scan-dashboard-0.mail>
2025-04-07 7:26 ` Jan Beulich
2025-04-07 7:43 ` Andrew Cooper
[not found] <67ed34047fd3c_1209992cc92a0f99a0989e0@prd-scan-dashboard-0.mail>
2025-04-02 14:19 ` Jan Beulich
2025-04-02 16:01 ` Andrew Cooper
[not found] <664dc165759df_5e9362b92d249399c762@prd-scan-dashboard-0.mail>
2024-05-22 10:05 ` Jan Beulich
2024-05-22 13:49 ` Andrew Cooper
[not found] <6637576caf98c_10d9e42c57d37559ac60499@prd-scan-dashboard-0.mail>
2024-05-06 7:46 ` Jan Beulich
[not found] <6547674e54da3_1c3af2c62521719a8359bc@prd-scan-dashboard-0.mail>
2023-11-06 7:36 ` Jan Beulich
[not found] <64859cf3a1e46_712752abb10eab98834b9@prd-scan-dashboard-0.mail>
2023-06-12 10:54 ` Jan Beulich
2023-06-12 11:06 ` Andrew Cooper
[not found] <600d4d7f99bc3_241662b17c874cf6097f1@prd-scan-dashboard-0.mail>
2021-01-25 10:14 ` Jan Beulich
[not found] <5700f7b3e7d5c_3fdf4db3186252@ss1435.mail>
2016-04-04 15:07 ` Ian Jackson
[not found] <56ce8ad13abd2_bd9abd33094410@ss1435.mail>
2016-02-25 10:00 ` Ian Campbell
2016-02-25 10:06 ` George Dunlap
[not found] <551be9e0474d8_2970d1331454394@scan.coverity.com.mail>
2015-04-02 14:32 ` Ian Campbell
2015-04-02 15:43 ` Charles Arnold
[not found] <E1Vgaam-0000UH-GS@build-l3.scan.coverity.com>
2013-11-13 13:51 ` Ian Campbell
2013-11-13 14:01 ` David Vrabel
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=DCNFIZNXYSZS.2SXOS2FXVOS4Z@amd.com \
--to=alejandro.garciavallejo@amd.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.