On Wed, Feb 19, 2020 at 9:06 AM Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > On Wed, Feb 19, 2020 at 8:56 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > > > On 2/19/20 1:42 AM, Yonghong Song wrote: > > > The latest llvm supports cpu version v3, which is cpu version v1 > > > plus some additional 64bit jmp insns and 32bit jmp insn support. > > > > > > In selftests/bpf Makefile, the llvm flag -mcpu=probe did runtime > > > probe into the host system. Depending on compilation environments, > > > it is possible that runtime probe may fail, e.g., due to > > > memlock issue. This will cause generated code with cpu version v1. > > > > But those are tiny BPF progs that LLVM is probing. If memlock is not > > sufficient, should it try to bump the limit with the diff needed and > > only if that fails as well then it bails out to v1. > > with hundred parallel clangs running and all stamping on the same rlimit > I don't think bumping that limit can work. > Also building on older kernel should still do v3, since build should > produce selftest binaries for the same vmlinux as this kernel tree. > We hit this issue with github/libbpf CI. The vm used to do the build > was too old. So far we cannot build vmlinux out of latest tree, > boot into it and only then build selftests inside. It's too complex > for CI system. > So we build vmlinux and build selftests in that CI's VM, and then boot into it > and run selftests. > Upgrading VM is an easy fix for now, but the issue will cause the problems > later. So imo fixing selftests build to predictable -mcpu=v3 is the > most sensible way. Applied. Thanks
