Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 14 Dec 2022 11:34:58 -0300
From:   Arnaldo Carvalho de Melo <acme@kernel.org>
To:     Thomas Richter <tmricht@linux.ibm.com>
Cc:     linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
        hca@linux.ibm.com, gor@linux.ibm.com, sumanthk@linux.ibm.com,
        svens@linux.ibm.com
Subject: Re: [PATCH 2/2] perf/test: Fix perf test 89 on x86
Message-ID: <Y5nfEu+3sU/Hcoon@kernel.org>
References: <20221213105729.1447368-1-tmricht@linux.ibm.com>
 <20221213105729.1447368-2-tmricht@linux.ibm.com>
 <Y5iQXJaQOrhjLZQW@kernel.org>
 <f5e69102-ed17-1f2d-3a09-3c7968b611ff@linux.ibm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <f5e69102-ed17-1f2d-3a09-3c7968b611ff@linux.ibm.com>
Precedence: bulk

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