xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
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


  reply	other threads:[~2025-09-08 12:49 UTC|newest]

Thread overview: 24+ 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] <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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).