All of lore.kernel.org
 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: 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.