linux-kernel - Re: [backport PATCH 0/2] stable v5.15, v5.10 and v5.4: fix perf build errors

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] [day] [month] [year] [list]

Message-ID: <CAP-5=fVDQWshLtjXkqogOkhJT2z9aEFcpjY32pjQ6DbFrMy88Q@mail.gmail.com>
Date:   Thu, 20 Apr 2023 13:34:08 -0700
From:   Ian Rogers <irogers@...gle.com>
To:     Anders Roxell <anders.roxell@...aro.org>
Cc:     Greg KH <gregkh@...uxfoundation.org>, stable@...r.kernel.org,
        acme@...hat.com, andres@...razel.de, linux-kernel@...r.kernel.org,
        linux-perf-users@...r.kernel.org
Subject: Re: [backport PATCH 0/2] stable v5.15, v5.10 and v5.4: fix perf build errors

On Thu, Apr 20, 2023 at 11:24 AM Anders Roxell <anders.roxell@...aro.org> wrote:
>
> On Tue, 18 Apr 2023 at 11:04, Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > On Mon, Apr 17, 2023 at 02:29:41PM +0200, Anders Roxell wrote:
> > > Hi,
> > >
> > > I would like to see these patches backported. They are needed so perf
> > > can be cross compiled with gcc on v5.15, v5.10 and v5.4.
> > > I built it with tuxmake [1] here are two example commandlines:
> > > tuxmake --runtime podman --target-arch arm64 --toolchain gcc-12 --kconfig defconfig perf
> > > tuxmake --runtime podman --target-arch x86_64 --toolchain gcc-12 --kconfig defconfig perf
> > >
> > > Tried to build perf with both gcc-11 and gcc-12.
> > >
> > > Patch 'tools perf: Fix compilation error with new binutils'
> > > and 'tools build: Add feature test for init_disassemble_info API changes'
> > > didn't apply cleanly, thats why I send these in a patchset.
> > >
> > > When apply 'tools build: Add feature test for
> > > init_disassemble_info API changes' to 5.4 it will be a minor merge
> > > conflict, do you want me to send this patch in two separate patches one
> > > for 5.4 and another for v5.10?
> > >
> > > The sha for these two patches in mainline are.
> > > cfd59ca91467 tools build: Add feature test for init_disassemble_info API changes
> > > 83aa0120487e tools perf: Fix compilation error with new binutils
> > >
> > > The above patches solves these:
> > > util/annotate.c: In function 'symbol__disassemble_bpf':
> > > util/annotate.c:1729:9: error: too few arguments to function 'init_disassemble_info'
> > >  1729 |         init_disassemble_info(&info, s,
> > >       |         ^~~~~~~~~~~~~~~~~~~~~
> > >
> > >
> > > Please apply these to v5.10 and v5.4
> > > a45b3d692623 tools include: add dis-asm-compat.h to handle version differences
> > > d08c84e01afa perf sched: Cast PTHREAD_STACK_MIN to int as it may turn into sysconf(__SC_THREAD_STACK>
> > >
> > > The above patches solves these:
> > > /home/anders/src/kernel/stable-5.10/tools/include/linux/kernel.h:43:24: error: comparison of distinct pointer types lacks a cast [-Werror]
> > >    43 |         (void) (&_max1 == &_max2);              \
> > >       |                        ^~
> > > builtin-sched.c:673:34: note: in expansion of macro 'max'
> > >   673 |                         (size_t) max(16 * 1024, PTHREAD_STACK_MIN));
> > >       |                                  ^~~
> > >
> > >
> > > Please apply these to v5.15, v5.10 and v5.4
> > > 8e8bf60a6754 perf build: Fixup disabling of -Wdeprecated-declarations for the python scripting engine
> > > 4ee3c4da8b1b perf scripting python: Do not build fail on deprecation warnings
> > > 63a4354ae75c perf scripting perl: Ignore some warnings to keep building with perl headers
> >
> > Can you please provide patch series of these upstream commits backported
> > to the relevant branchs that you wish to see them in?  You have 2
> > patches in this series without git commit ids, and I have no idea where
> > to apply them, or not apply them...
>
> Yes, apologies, I will get that fixed up.
>
> >
> > Or better yet, just use the latest version of perf as was pointed out,
> > on these old kernel releases.
>
> Makes sense, we can do this. Is this the preferred way going forward?

Fwiw, it definitely has my vote.

Thanks,
Ian

> Cheers,
> Anders