From: David Vrabel <david.vrabel@citrix.com>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: xen-devel@lists.xen.org
Subject: Re: New Defects reported by Coverity Scan for XenProject
Date: Wed, 13 Nov 2013 14:01:21 +0000 [thread overview]
Message-ID: <52838631.6040900@citrix.com> (raw)
In-Reply-To: <1384350685.5406.117.camel@kazak.uk.xensource.com>
On 13/11/13 13:51, Ian Campbell wrote:
> Hi David,
>
> Coverity picked up some issues in the kexec patches. At least the
> locking one looks valid to me...
Thanks. Andy just pointed them out to me as well.
> I didn't investigate the endianness one.
We believe these are coverity being confused by the underlying
atomic_read()/atomic_write() macros and getting the type wrong.
David
> On Wed, 2013-11-13 at 05:34 -0800, scan-admin@coverity.com wrote:
>> ________________________________________________________________________
>> CID 1128573: Missing unlock (LOCK)
>>
>> /xen/common/kexec.c: 788 ( lock)
>> 785
>> 786 *old = NULL;
>> 787
>>>>> "_spin_lock(spinlock_t *)" locks "kexec_lock".
>> 788 spin_lock(&kexec_lock);
>> 789
>> 790 if ( test_bit(KEXEC_FLAG_IN_PROGRESS, &kexec_flags) )
>> 791 {
>> 792 spin_unlock(&kexec_lock);
>>
>>
>> /xen/common/kexec.c: 797 ( missing_unlock)
>> 794 }
>> 795
>> 796 if ( kexec_load_get_bits(type, &base, &bit) )
>>>>> CID 1128573: Missing unlock (LOCK)
>>>>> Returning without unlocking "kexec_lock".
>> 797 return -EINVAL;
>> 798
>> 799 pos = (test_bit(bit, &kexec_flags) != 0);
>> 800 old_slot = base + pos;
>> 801 new_slot = base + !pos;
>>
>> ________________________________________________________________________
>> CID 1128572: Reliance on integer endianness (INCOMPATIBLE_CAST)
>>
>> /xen/arch/x86/machine_kexec.c: 58 ( incompatible_cast)
>> 55 l3_page = kimage_alloc_control_page(image, 0);
>> 56 if ( !l3_page )
>> 57 goto out;
>>>>> CID 1128572: Reliance on integer endianness (INCOMPATIBLE_CAST)
>>>>> Pointer "&l4->l4" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness.
>> 58 l4e_write(l4, l4e_from_page(l3_page, __PAGE_HYPERVISOR));
>> 59 }
>> 60 else
>> 61 l3_page = l4e_get_page(*l4);
>> 62
>>
>> ________________________________________________________________________
>> CID 1128571: Reliance on integer endianness (INCOMPATIBLE_CAST)
>>
>> /xen/arch/x86/machine_kexec.c: 70 ( incompatible_cast)
>> 67 l2_page = kimage_alloc_control_page(image, 0);
>> 68 if ( !l2_page )
>> 69 goto out;
>>>>> CID 1128571: Reliance on integer endianness (INCOMPATIBLE_CAST)
>>>>> Pointer "&l3->l3" points to an object whose effective type is "unsigned long" (64 bits, unsigned) but is dereferenced as a narrower "unsigned int" (32 bits, unsigned). This may lead to unexpected results depending on machine endianness.
>> 70 l3e_write(l3, l3e_from_page(l2_page, __PAGE_HYPERVISOR));
>> 71 }
>> 72 else
>> 73 l2_page = l3e_get_page(*l3);
>> 74
>>
>> ________________________________________________________________________
>> To view the defects in Coverity Scan visit, http://scan.coverity.com
next prev parent reply other threads:[~2013-11-13 14:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1Vgaam-0000UH-GS@build-l3.scan.coverity.com>
2013-11-13 13:51 ` New Defects reported by Coverity Scan for XenProject Ian Campbell
2013-11-13 14:01 ` David Vrabel [this message]
[not found] <551be9e0474d8_2970d1331454394@scan.coverity.com.mail>
2015-04-02 14:32 ` Ian Campbell
2015-04-02 15:43 ` Charles Arnold
[not found] <56ce8ad13abd2_bd9abd33094410@ss1435.mail>
2016-02-25 10:00 ` Ian Campbell
2016-02-25 10:06 ` George Dunlap
[not found] <5700f7b3e7d5c_3fdf4db3186252@ss1435.mail>
2016-04-04 15:07 ` Ian Jackson
[not found] <600d4d7f99bc3_241662b17c874cf6097f1@prd-scan-dashboard-0.mail>
2021-01-25 10:14 ` 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] <6547674e54da3_1c3af2c62521719a8359bc@prd-scan-dashboard-0.mail>
2023-11-06 7:36 ` Jan Beulich
[not found] <6637576caf98c_10d9e42c57d37559ac60499@prd-scan-dashboard-0.mail>
2024-05-06 7:46 ` Jan Beulich
[not found] <664dc165759df_5e9362b92d249399c762@prd-scan-dashboard-0.mail>
2024-05-22 10:05 ` Jan Beulich
2024-05-22 13:49 ` Andrew Cooper
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=52838631.6040900@citrix.com \
--to=david.vrabel@citrix.com \
--cc=Ian.Campbell@citrix.com \
--cc=xen-devel@lists.xen.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).