linux-kernel - Re: [PATCH] perf tools: Fix object code reading for PTI entry trampolines

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]

Message-ID: <20180605153145.GI4899@kernel.org>
Date:   Tue, 5 Jun 2018 12:31:45 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     Jiri Olsa <jolsa@...hat.com>, linux-kernel@...r.kernel.org,
        linux-perf-users@...r.kernel.org
Subject: Re: [PATCH] perf tools: Fix object code reading for PTI entry
 trampolines

Em Tue, Jun 05, 2018 at 05:08:35PM +0300, Adrian Hunter escreveu:
> On 05/06/18 16:41, Arnaldo Carvalho de Melo wrote:
> > And this test fails way less often, but still does, for instance:

> > # while true ; do perf test -v object 2>out.txt ; grep -i fail out.txt && break ; done
> > dso__data_read_offset failed
> > Object code reading: FAILED!
> > #
> > [root@...enth ~]# tail out.txt 
> > File is: /proc/kcore
> > On file address is: 0x7fff892300df
> > kcore map tested already - skipping
> > Reading object code for memory address: 0x4a020f
> > File is: /home/acme/bin/perf (deleted)
> > On file address is: 0xa020f
> > dso__data_read_offset failed
> > test child finished with -1
> > ---- end ----
> > Object code reading: FAILED!
> > [root@...enth ~]#

> > I start that loop and then try running 'make -C tools/perf O=/tmp/build/perf install-bin',
> > to generate some load.

> So is it related to the "deleted" in "File is: /home/acme/bin/perf (deleted)"?

Probably, Jiri? Probably it'll be difficult to sort this out, as the
original for that file probably isn't available anymore and probably we
didn't had the opportunity to have already read its build-id to lookup
it in the ~/.debug/ cache... So probably we should notice that and skip
this, not considering it as an error?

- Arnaldo