Ian Campbell
2013-Nov-13 13:51 UTC
Re: New Defects reported by Coverity Scan for XenProject
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@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 > > To unsubscribe from the email notification for new defects, http://scan5.coverity.com/cgi-bin/unsubscribe.py
David Vrabel
2013-Nov-13 14:01 UTC
Re: New Defects reported by Coverity Scan for XenProject
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