linux-kernel - [RFC PATCHSET] perf: Fix cpu/thread map and group event handling

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: <1329119048-9615-1-git-send-email-namhyung.kim@lge.com>
Date:	Mon, 13 Feb 2012 16:44:08 +0900
From:	Namhyung Kim <namhyung.kim@....com>
To:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Cc:	Namhyung Kim <namhyung@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>,
	linux-kernel@...r.kernel.org
Subject: [RFC PATCHSET] perf: Fix cpu/thread map and group event handling

Resend as it was not sent to LKML due to my cccmd problem.

=====================
Hello,

When I was playing with event group, I found a bug that didn't count
such events properly. After looking at the code, it seemed there were
few more bugs, so I decided to refactor the code during fixing them.

The first one I found was that 'perf stat --group' doesn't count any
event but the first. It was a bug on setting attr->disabled and
attr->enable_on_exec to a member of a group event. And it was related
to the code which decides the target task/cpu that those events are
attached to. They did same things, but were separated to each file.

To clean it up, I've made a new struct and used it for record, stat,
top and test. During the cleanup I found some combinations of PID/TID,
UID and CPU weren't allowed and had implicit behaviors. For example,
'perf record -- sleep 1' will create multiple events as much as number
of online cpus on the system. I don't think it's intended. So they
should be fixed and warned to user explicitly, if needed.

I think we have following prorities and implications:

 * If -p option is given, -t option should be ignored.
 * If -p or -t option is given, -u, -C and/or -a options should be ignored.
 * If -u option is given, -C and/or -a option should be ignored.

And if only -C option is given, it should be treated as a system-wide
mode. Also if *NO* option is given (i.e. fork a child for command line
argument), it should be treated as a task mode, not a system-wide mode.

These patches are based on latest tip/perf/core: f8d98f109521 ("x86:
Fix to decode grouped AVX with VEX pp bits").

Any comments are welcome.
Thanks.

Namhyung Kim (11):
  perf tools: Introduce struct perf_maps_opts
  perf stat: Convert to perf_maps_opts
  perf top: Convert to perf_maps_opts
  perf tools: Introduce check_target_maps() helper
  perf tools: Make perf_evlist__create_maps() take struct perf_maps_opts
  perf tools: Check more combinations of PID/TID, UID and CPU switches
  perf tools: Fix creation of cpu map
  perf tools: Consolidate target task/cpu checking
  perf stat: Use perf_evlist__create_maps
  perf stat: Fix event grouping on forked task
  perf record: Fix event grouping on forked task

 tools/perf/builtin-record.c |   42 ++++++++++++++----------------
 tools/perf/builtin-stat.c   |   56 ++++++++++++++++------------------------
 tools/perf/builtin-test.c   |   12 +++++---
 tools/perf/builtin-top.c    |   41 ++++++++++++-----------------
 tools/perf/perf.h           |   11 ++++++--
 tools/perf/util/evlist.c    |   20 ++++++++------
 tools/perf/util/evlist.h    |    7 +++--
 tools/perf/util/evsel.c     |   11 ++++---
 tools/perf/util/evsel.h     |    3 +-
 tools/perf/util/top.c       |   15 ++++++-----
 tools/perf/util/top.h       |    4 +--
 tools/perf/util/usage.c     |   59 +++++++++++++++++++++++++++++++++++++------
 tools/perf/util/util.h      |    7 ++++-
 13 files changed, 163 insertions(+), 125 deletions(-)

-- 
1.7.9

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