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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
