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>] [day] [month] [year] [list]
Message-ID: <54D23946.6000106@hitachi.com>
Date:	Thu, 05 Feb 2015 00:22:46 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Arnaldo Carvalho de Melo <acme@...hat.com>, namhyung@...nel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>,
	Ingo Molnar <mingo@...hat.com>
Cc:	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Perf buildid-cache gives a confusing message

Hi,
(Sorry, I missed CC to LKML)

I've found a bit odd perf-buildid-cache behavior. It seems
to be as designed, but also a bit confusing.

Issue: perf-buildid-cache's --update and --remove operations
refer the current existing binary at given path. This means
if we update the old binary, it couldn't remove nor update
the buildid-cache.

Here is the example,
  ----
  [mhiramat@...alhost perf]$ ./perf buildid-cache -v --add ./perf
  Adding 51d0731187917e27fd733f2f6f34777cddbaec0f ./perf: Ok  <-- (*)
  [mhiramat@...alhost perf]$ rm perf
  [mhiramat@...alhost perf]$ make clean
  [mhiramat@...alhost perf]$ make
  [mhiramat@...alhost perf]$ ./perf buildid-cache -v --update ./perf
  Updating 45a97daa65f9c58adeb34af4158a6dde747de49b ./perf: FAIL <-- (*)
  ./perf wasn't in the cache
  [mhiramat@...alhost perf]$ ./perf buildid-cache -v --remove ./perf
  Removing 45a97daa65f9c58adeb34af4158a6dde747de49b ./perf: FAIL <-- (*)
  ./perf wasn't in the cache
  ----
Both --update and --remove are failed after updating local binary.
Note that (*) are verbose message, without -v we don't see that.

I know this is the designed behavior, buildid-cache manages binaries
based on its build-id, not its path. However, it seems confusing.

So, I'd like to suggest to fix --update FILE to add new binary to cache
when there is no current binary cache (this will fix the first FAIL),
and add --remove-all FILE to remove all existing buildid cache about FILE
(path-based cleanup).
What would you think about that?

Thank you,
-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ