Re: [RFC] Coverity 1128445 - Reliance on integer endianness

[Peter Zijlstra]

On Tue, Nov 12, 2013 at 12:19:13PM -0200, Geyslan Gregório Bem wrote:
> Hi,
> 
> Coverity detected in 'arch/x86/kernel/cpu/perf_event_intel_uncore.c' a
> possible reliance on integer endianness. Is that a positive one?
> 
> static u64 ivt_uncore_irp_read_counter(struct intel_uncore_box *box,
> struct perf_event *event)
> 1369{
> 1370        struct pci_dev *pdev = box->pci_dev;
> 1371        struct hw_perf_event *hwc = &event->hw;
> 1372        u64 count = 0;
> 1373
> 
> CID 1128445 (#1 of 1): Reliance on integer endianness
> (INCOMPATIBLE_CAST)incompatible_cast: Pointer "&count" points to an
> object whose effective type is "unsigned long 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.[show details]
> 
> 1374        pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx],
> (u32 *)&count);
> 1375        pci_read_config_dword(pdev, ivt_uncore_irp_ctrs[hwc->idx]
> + 4, (u32 *)&count + 1);
> 1376
> 1377        return count;
> 1378}

Right, its a bit ugly but since its all arch code (x86) we can indeed
assume endianness (little).

So yes Coverity is right but we can also ignore it since machine
endianness is fixed here.

The code loads the u64 in two pci dword reads and assumes the high dword
lives at the higher address, this is correct for little endian.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/