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] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 9 Jan 2023 19:10:18 +0100
From:   Jiri Olsa <olsajiri@...il.com>
To:     Arnaldo Carvalho de Melo <acme@...nel.org>
Cc:     Ian Rogers <irogers@...gle.com>,
        Mike Leach <mike.leach@...aro.org>,
        linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org,
        bpf@...r.kernel.org, peterz@...radead.org, mingo@...hat.com,
        mark.rutland@....com, alexander.shishkin@...ux.intel.com,
        namhyung@...nel.org
Subject: Re: [PATCH v3 1/2] perf build: Properly guard libbpf includes

On Mon, Jan 09, 2023 at 12:12:15PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jan 06, 2023 at 11:06:46AM -0800, Ian Rogers escreveu:
> > So trying to get build-test working on my Debian derived distro is a
> > PITA with broken feature detection for options I don't normally use.
> 
> Its really difficult to have perf building with so many dependent
> libraries, mowing out some should be in order.
> 
> > I'll try to fix this.
> 
> Thanks.
>  
> > In any case I think I've spotted what is really happening here and it
> > isn't a failure but a feature :-D The build is specifying
> 
> I get it.
> 
> > LIBBPF_DYNAMIC=1 which means you get the libbpf headers from
> > /usr/include. I think the build is trying to do this on a system with
> > an old libbpf and hence getting the failures above. Previously, even
> > though we wanted the dynamic headers we still had a -I, this time for
> > the install_headers version. Now you really are using the system
> > version and it is broken. This means a few things:
> > - the libbpf feature test should fail if code like above is going to fail,
> 
> Agreed.
> 
> > - we may want to contemplate supporting older libbpfs (I'd rather not),
> 
> I'd rather require everybody to be up to the latest trends, but I really
> don't think that is a reasonable expectation.
> 
> > - does build-test have a way to skip known issues like this?
> 
> Unsure, Jiri?

I don't think so it just triggers the build, it's up to the features check
to disable the feature if the library is not compatible with perf code

could we add that specific libbpf call to the libbpf feature check?

jirka

> 
> But yeah, previous experiences with Andrii were that we can do not too
> costly feature checks, not using .c programs that would fail if some
> required feature wasn't present but instead would just do some grep on a
> header and if some "smell" wasn't scent, just fail the cap query.
> 
> - Arnaldo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ