bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Shuah Khan <skhan@linuxfoundation.org>
To: Daniel Borkmann <daniel@iogearbox.net>
Cc: Yonghong Song <yhs@fb.com>,
	Alexei Starovoitov <alexei.starovoitov@gmail.com>,
	<linux-kselftest@vger.kernel.org>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Andrii Nakryiko <andriin@fb.com>,
	Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: Linux 5.4 - bpf test build fails
Date: Tue, 24 Sep 2019 12:56:53 -0600	[thread overview]
Message-ID: <edb38c06-a75f-89df-60cd-d9d2de1879d6@linuxfoundation.org> (raw)
In-Reply-To: <20190924184946.GB5889@pc-63.home>

On 9/24/19 12:49 PM, Daniel Borkmann wrote:
> On Tue, Sep 24, 2019 at 09:48:35AM -0600, Shuah Khan wrote:
>> On 9/24/19 9:43 AM, Yonghong Song wrote:
>>> On 9/24/19 8:26 AM, Shuah Khan wrote:
>>>> Hi Alexei and Daniel,
>>>> bpf test doesn't build on Linux 5.4 mainline. Do you know what's
>>>> happening here.
>>>> make -C tools/testing/selftests/bpf/
>>>> -c progs/test_core_reloc_ptr_as_arr.c -o - || echo "clang failed") | \
>>>> llc -march=bpf -mcpu=generic  -filetype=obj -o
>>>> /mnt/data/lkml/linux_5.4/tools/testing/selftests/bpf/test_core_reloc_ptr_as_arr.o
>>>> progs/test_core_reloc_ptr_as_arr.c:25:6: error: use of unknown builtin
>>>>          '__builtin_preserve_access_index' [-Wimplicit-function-declaration]
>>>>            if (BPF_CORE_READ(&out->a, &in[2].a))
>>>>                ^
>>>> ./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
>>>>                           __builtin_preserve_access_index(src))
>>>>                           ^
>>>> progs/test_core_reloc_ptr_as_arr.c:25:6: warning: incompatible integer to
>>>>          pointer conversion passing 'int' to parameter of type 'const void *'
>>>>          [-Wint-conversion]
>>>>            if (BPF_CORE_READ(&out->a, &in[2].a))
>>>>                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> ./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
>>>>                           __builtin_preserve_access_index(src))
>>>>                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>> 1 warning and 1 error generated.
>>>> llc: error: llc: <stdin>:1:1: error: expected top-level entity
>>>> clang failed
>>>> Also
>>>> make TARGETS=bpf kselftest fails as well. Dependency between
>>>> tools/lib/bpf and the test. How can we avoid this type of
>>>> dependency or resolve it in a way it doesn't result in build
>>>> failures?
>>> Thanks, Shuah.
>>> The clang __builtin_preserve_access_index() intrinsic is
>>> introduced in LLVM9 (which just released last week) and
>>> the builtin and other CO-RE features are only supported
>>> in LLVM10 (current development branch) with more bug fixes
>>> and added features.
>>> I think we should do a feature test for llvm version and only
>>> enable these tests when llvm version >= 10.
>> Yes. If new tests depend on a particular llvm revision, the failing
>> the build is a regression. I would like to see older tests that don't
>> have dependency build and run.
> So far we haven't made it a requirement as majority of BPF contributors
> that would run/add tests in here are also on bleeding edge LLVM anyway
> and other CIs like 0-day bot have simply upgraded their LLVM version
> from git whenever there was a failure similar to the one here so its
> ensured that really /all/ test cases are running and nothing would be
> skipped. There is worry to some degree that CIs just keep sticking to
> an old compiler since tests "just" pass and regressions wouldn't be
> caught on new releases for those that are skipped. >

Sure. Bleeding edge is developer mode. We still have to be concerned
about users that might not upgrade quickly.

> That said, for the C based tests, it should actually be straight forward
> to categorize them based on built-in macros like ...
> $ echo | clang -dM -E -
> [...]
> #define __clang_major__ 10
> #define __clang_minor__ 0
> [...]

What would nice running the tests you can run and then say some tests
aren't going to run. Is this something you can support?

> ... given there is now also bpf-gcc, the test matrix gets bigger anyway,
> so it might be worth rethinking to run the suite multiple times with
> different major llvm{,gcc} versions at some point to make sure their
> generated BPF bytecode keeps passing the verifier, and yell loudly if
> newer features had to be skipped due to lack of recent compiler version.
> This would be a super set of /just/ skipping tests and improve coverage
> at the same time.

Probably. Reality is most users will just quit and add bpf to "hard to
run category" of tests.

-- Shuah

  reply	other threads:[~2019-09-24 18:56 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-24 15:26 Linux 5.4 - bpf test build fails Shuah Khan
2019-09-24 15:43 ` Yonghong Song
2019-09-24 15:48   ` Shuah Khan
2019-09-24 18:49     ` Daniel Borkmann
2019-09-24 18:56       ` Shuah Khan [this message]
2019-09-24 19:19         ` Daniel Borkmann
2019-09-24 19:48           ` Shuah Khan
2019-09-24 15:52 ` Cristian Marussi
2019-09-24 16:03   ` Shuah Khan
2019-09-24 16:39     ` Shuah Khan
2019-09-24 17:29       ` Cristian Marussi
2019-09-24 18:07         ` Tim.Bird
2019-09-24 18:23           ` Shuah Khan
2019-09-25  8:52             ` Cristian Marussi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=edb38c06-a75f-89df-60cd-d9d2de1879d6@linuxfoundation.org \
    --to=skhan@linuxfoundation.org \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andriin@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=yhs@fb.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).