netdev - Re: [PATCH v2 0/7] Copy hashmap to tools/perf/util, use in perf expr

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:   Fri, 15 May 2020 14:47:29 -0700
From:   Ian Rogers <irogers@...gle.com>
To:     Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>,
        Kajol Jain <kjain@...ux.ibm.com>,
        Andi Kleen <ak@...ux.intel.com>,
        John Garry <john.garry@...wei.com>,
        Jin Yao <yao.jin@...ux.intel.com>,
        Kan Liang <kan.liang@...ux.intel.com>,
        Cong Wang <xiyou.wangcong@...il.com>,
        Kim Phillips <kim.phillips@....com>,
        Adrian Hunter <adrian.hunter@...el.com>,
        Leo Yan <leo.yan@...aro.org>,
        open list <linux-kernel@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 0/7] Copy hashmap to tools/perf/util, use in perf expr

On Fri, May 15, 2020 at 2:19 PM <arnaldo.melo@...il.com> wrote:
>
> <bpf@...r.kernel.org>,Stephane Eranian <eranian@...gle.com>
> From: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
> Message-ID: <79BCBAF7-BF5F-4556-A923-56E9D82FB570@...il.com>
>
>
>
> On May 15, 2020 4:42:46 PM GMT-03:00, Andrii Nakryiko <andrii.nakryiko@...il.com> wrote:
> >On Fri, May 15, 2020 at 10:01 AM Arnaldo Carvalho de Melo
> ><arnaldo.melo@...il.com> wrote:
> >>
> >> Em Fri, May 15, 2020 at 09:50:00AM -0700, Ian Rogers escreveu:
> >> > Perf's expr code currently builds an array of strings then removes
> >> > duplicates. The array is larger than necessary and has recently
> >been
> >> > increased in size. When this was done it was commented that a
> >hashmap
> >> > would be preferable.
> >> >
> >> > libbpf has a hashmap but libbpf isn't currently required to build
> >> > perf. To satisfy various concerns this change copies libbpf's
> >hashmap
> >> > into tools/perf/util, it then adds a check in perf that the two are
> >in
> >> > sync.
> >> >
> >> > Andrii's patch to hashmap from bpf-next is brought into this set to
> >> > fix issues with hashmap__clear.
> >> >
> >> > Two minor changes to libbpf's hashmap are made that remove an
> >unused
> >> > dependency and fix a compiler warning.
> >>
> >> Andrii/Alexei/Daniel, what do you think about me merging these fixes
> >in my
> >> perf-tools-next branch?
> >
> >I'm ok with the idea, but it's up to maintainers to coordinate this :)
>
> Good to know, do I'll take all patches except the ones touching libppf, will just make sure the copy is done with the patches applied.
>
> At some point they'll land in libbpf and the warning from check_headers.sh will be resolved.

So tools/perf/util's hashmap will be ahead of libbpf's, as without the
fixes the perf build is broken by Werror. This will cause
check_headers to warn in perf builds, which would usually mean our
header was older than the source one, but in this case it means the
opposite, we're waiting for the libbpf patches to merge. Aside from
some interim warnings everything will resolve itself and Arnaldo
avoids landing patches in libbpf that can interfere with bpf-next.

It takes some getting your head around but sounds good to me :-) I
think the only workable alternatives would be to explore having a
single version of the code in some kind of shared libhashmap or to
implement another hashmap in libapi. I'd like to get the rest of this
work unblocked and so it'd be nice to land this and we can always
refactor later - I like Arnaldo's plan. Can a bpf maintainer make sure
the hashmap changes get pulled into bpf-next?

Thanks!
Ian

> Thanks,
>
> - Arnaldo
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.