Re: [Xen-devel] New Defects reported by Coverity Scan for XenProject

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

Hi David,

Coverity picked up some issues in the kexec patches. At least the
locking one looks valid to me...

I didn't investigate the endianness one.

Ian.

On Wed, 2013-11-13 at 05:34 -0800, scan-admin@xxxxxxxxxxxx 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
> 
> To unsubscribe from the email notification for new defects, 
> http://scan5.coverity.com/cgi-bin/unsubscribe.py



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel