linux-kernel - Re: [PATCH net-next] bpf: update perf event helper function signature and documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 25 May 2017 12:07:35 -0400 (EDT)
From:   David Miller <davem@...emloft.net>
To:     qinteng@...com
Cc:     peterz@...radead.org, bgregg@...flix.com, daniel@...earbox.net,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Kernel-team@...com, ast@...com
Subject: Re: [PATCH net-next] bpf: update perf event helper function
 signature and documentation

From: Teng Qin <qinteng@...com>
Date: Tue, 23 May 2017 03:17:31 +0000

> Alexei said it was due to Clang not taking u64, u32 etc. for compilation.
> I didn’t know the context and just used them. But apparently, something
> changed and now they build and run OK......

These types are %100 compiler agnostic.  Clang doesn't care.  All
compilers can understand:

	typedef unsigned int u32;

So it's not a Clang specific issue.

The problem could only have to do with whether the types get typdef'd
or not with the header files that are used in conjunction with the
file we are talking about here.

And if we do get a proper set of defines from linux/types.h these days
we should:

1) Make that explicit, by including linux/types.h in bpf_helpers.h

2) Use those types universally in this file where we were avoiding
   doing so

This header file also uses "SEC" and expects to get this definition
implicitly, and therefore there is another header file that
bpf_helpers.h must include in order to explicitly and reliably have
that definition.

Just changing one prototype, and relying on getting the types
indirectly by other header files including by whoever incudes
bpf_helpers.h is not the way to go.

Thanks.