On 5/17/17 4:01 PM, David Miller wrote:
From: Daniel Borkmann <dan...@iogearbox.net>
Date: Thu, 18 May 2017 00:57:04 +0200

On 05/18/2017 12:18 AM, Yonghong Song wrote:
Commit 0a5539f66133 ("bpf: Provide a linux/types.h override
for bpf selftests.") caused a build failure for
tools/testing/selftest/bpf
because of some missing types:
      $ make -C tools/testing/selftests/bpf/
      ...
      In file included from
      /home/yhs/work/net-next/tools/testing/selftests/bpf/test_pkt_access.c:8:
      ../../../include/uapi/linux/bpf.h:170:3: error: unknown type name
      '__aligned_u64'
                      __aligned_u64   key;
      ...
      /usr/include/linux/swab.h:160:8: error: unknown type name
      '__always_inline'
      static __always_inline __u16 __swab16p(const __u16 *p)
      ...
The type __aligned_u64 is defined in linux:include/uapi/linux/types.h.

The fix is to copy missing type definition into
tools/testing/selftests/bpf/include/uapi/linux/types.h.
Adding additional include "string.h" resolves __always_inline issue.

Fixes: 0a5539f66133 ("bpf: Provide a linux/types.h override for bpf
selftests.")
Signed-off-by: Yonghong Song <y...@fb.com>

Can you elaborate why string.h specifically? Can't we define the
__always_inline ourselves?

That way it comes from compiler.h

Just a little bit correction. The __always_inline is not from compiler.h. The compiler.h is inside kernel source tree. Currently,
programs in selftests do not directly referencing kernel header
files (except test_verifier trying to do with alignment)

======
#ifdef HAVE_GENHDR
# include "autoconf.h"
#else
# if defined(__i386) || defined(__x86_64) || defined(__s390x__) || defined(__aarch64__)
#  define CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS 1
# endif
#endif
=====
(The above part may be gone soon with recent alignment tracking patch)

[yhs@localhost include]$ pwd
/usr/include
[yhs@localhost include]$ find . -name "compiler.h"
[yhs@localhost include]$

The __always_inline comes from sys/cdefs.h
sys/cdefs.h:# define __always_inline __inline __attribute__ ((__always_inline))

The following is the include chain leading to __always_inline:
string.h
   features.h
      sys/cdefs.h

Yes, it is deeply embedded in chain of header files and hard
to figure out intuitively....

Yonghong


Probably it would have been better to have the BPF linux/types.h bring
it in.

Sorry I applied this so quickly, I wanted this regression fixed as fast
as possible.

Reply via email to