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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ