linux-kernel - Re: [PATCH 2/2] perf/test: Fix perf test 89 on x86

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: <Y5nfEu+3sU/Hcoon@kernel.org>
Date:   Wed, 14 Dec 2022 11:34:58 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Thomas Richter <tmricht@...ux.ibm.com>
Cc:     linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        hca@...ux.ibm.com, gor@...ux.ibm.com, sumanthk@...ux.ibm.com,
        svens@...ux.ibm.com
Subject: Re: [PATCH 2/2] perf/test: Fix perf test 89 on x86

Em Wed, Dec 14, 2022 at 11:40:32AM +0100, Thomas Richter escreveu:
> On 12/13/22 15:46, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Dec 13, 2022 at 11:57:29AM +0100, Thomas Richter escreveu:
> >> perf test '89: probe libc's inet_pton & backtrace it with ping'
> >> fails on x86. Debugging revealed a changed stack trace for the
> >> ping command using probes:

> >> ping 35729 [002]  8006.365063: probe_libc:inet_pton: (3ff9603e7c0)
> >>                   12be50 __GI___inet_pton+0x0 (/usr/lib64/libc.so.6)
> >>                   4fca main+0x139b (/usr/bin/ping)

> >> The line getaddrinfo.... in the call stack is gone.
> >> It was introduced with glibc version 2.36.8 released
> >> with Fedora 37.

> >> Output before on x86
> >>  # ./perf test 89
> >>  89: probe libc's inet_pton & backtrace it with ping   : FAILED!
> >>  #

> >> Output after on x86:
> >>  # ./perf test 89
> >>  89: probe libc's inet_pton & backtrace it with ping   : Ok
> >>  #

> > Not having at the current state of that script, that $expected may be a
> > subset of the actual backtrace, i.e. will this continue working with
> > the systems where that getaddrinfo line appear?
 
> No, that is not the case.
> Taking this into account requires a larger rework of the call stack
> checking. Not just simple line by line matching which is done now.
> It also raises the question of how far to go back
> in glibc history. Different versions of glibc have different call stacks.
 
> I will rethink this...

One possibility is to have the options on a temp file, the previous one,
then if it fails, remove the getaddrinfo line and try again, if it
works, its the new glibc, test result is Ok.

Add a commment stating that from circa glibc versiuon 2.36.8 the
getaddrinfo isn't there anymore.

- Arnaldo