All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@kernel.org>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>,
	lkml <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Stanislav Fomichev <sdf@fomichev.me>,
	Song Liu <songliubraving@fb.com>, Andi Kleen <ak@linux.intel.com>
Subject: [PATCH 08/12] perf tools: Preserve eBPF maps when loading kcore
Date: Fri,  3 May 2019 10:18:37 +0200	[thread overview]
Message-ID: <20190503081841.1908-9-jolsa@kernel.org> (raw)
In-Reply-To: <20190503081841.1908-1-jolsa@kernel.org>

We need to preserve eBPF maps even if they are
covered by kcore, because we need to access
eBPF dso for source data.

Adding map_groups__merge_in function to do that.
It merges map into map_groups by splitting the
new map within the existing map regions.

Suggested-by: Adrian Hunter <adrian.hunter@intel.com>
Link: http://lkml.kernel.org/n/tip-mlu13e9zl6rbsz4fa00x7mfa@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
 tools/perf/util/symbol.c | 97 ++++++++++++++++++++++++++++++++++++++--
 1 file changed, 93 insertions(+), 4 deletions(-)

diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 5cbad55cd99d..29780fcd049c 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1166,6 +1166,85 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)
 	return 0;
 }
 
+/*
+ * Merges map into map_groups by splitting the new map
+ * within the existing map regions.
+ */
+static int map_groups__merge_in(struct map_groups *kmaps, struct map *new_map)
+{
+	struct map *old_map;
+	LIST_HEAD(merged);
+
+	for (old_map = map_groups__first(kmaps); old_map;
+	     old_map = map_groups__next(old_map)) {
+
+		/* no overload with this one */
+		if (new_map->end < old_map->start ||
+		    new_map->start >= old_map->end)
+			continue;
+
+		if (new_map->start < old_map->start) {
+			/*
+			 * |new......
+			 *       |old....
+			 */
+			if (new_map->end < old_map->end) {
+				/*
+				 * |new......|     -> |new..|
+				 *       |old....| ->       |old....|
+				 */
+				new_map->end = old_map->start;
+			} else {
+				/*
+				 * |new.............| -> |new..|       |new..|
+				 *       |old....|    ->       |old....|
+				 */
+				struct map *m = map__clone(new_map);
+
+				if (!m)
+					return -ENOMEM;
+
+				m->end = old_map->start;
+				list_add_tail(&m->node, &merged);
+				new_map->start = old_map->end;
+			}
+		} else {
+			/*
+			 *      |new......
+			 * |old....
+			 */
+			if (new_map->end < old_map->end) {
+				/*
+				 *      |new..|   -> x
+				 * |old.........| -> |old.........|
+				 */
+				map__put(new_map);
+				new_map = NULL;
+				break;
+			} else {
+				/*
+				 *      |new......| ->         |new...|
+				 * |old....|        -> |old....|
+				 */
+				new_map->start = old_map->end;
+			}
+		}
+	}
+
+	while (!list_empty(&merged)) {
+		old_map = list_entry(merged.next, struct map, node);
+		list_del_init(&old_map->node);
+		map_groups__insert(kmaps, old_map);
+		map__put(old_map);
+	}
+
+	if (new_map) {
+		map_groups__insert(kmaps, new_map);
+		map__put(new_map);
+	}
+	return 0;
+}
+
 static int dso__load_kcore(struct dso *dso, struct map *map,
 			   const char *kallsyms_filename)
 {
@@ -1222,7 +1301,12 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
 	while (old_map) {
 		struct map *next = map_groups__next(old_map);
 
-		if (old_map != map)
+		/*
+		 * We need to preserve eBPF maps even if they are
+		 * covered by kcore, because we need to access
+		 * eBPF dso for source data.
+		 */
+		if (old_map != map && !__map__is_bpf_prog(old_map))
 			map_groups__remove(kmaps, old_map);
 		old_map = next;
 	}
@@ -1256,11 +1340,16 @@ static int dso__load_kcore(struct dso *dso, struct map *map,
 			map_groups__remove(kmaps, map);
 			map_groups__insert(kmaps, map);
 			map__put(map);
+			map__put(new_map);
 		} else {
-			map_groups__insert(kmaps, new_map);
+			/*
+			 * Merge kcore map into existing maps,
+			 * and ensure that current maps (eBPF)
+			 * stay intact.
+			 */
+			if (map_groups__merge_in(kmaps, new_map))
+				goto out_err;
 		}
-
-		map__put(new_map);
 	}
 
 	if (machine__is(machine, "x86_64")) {
-- 
2.20.1


  parent reply	other threads:[~2019-05-03  8:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-03  8:18 [PATCHv2 00/12] perf tools: Display eBPF code in intel_pt trace Jiri Olsa
2019-05-03  8:18 ` [PATCH 01/12] perf tools: Separate generic code in dso__data_file_size Jiri Olsa
2019-05-03  8:18 ` [PATCH 02/12] perf tools: Separate generic code in dso_cache__read Jiri Olsa
2019-05-03  8:18 ` [PATCH 03/12] perf tools: Simplify dso_cache__read function Jiri Olsa
2019-05-03  8:18 ` [PATCH 04/12] perf tools: Add bpf dso read and size hooks Jiri Olsa
2019-05-03  8:18 ` [PATCH 05/12] perf tools: Read also the end of the kernel Jiri Olsa
2019-05-03  8:18 ` [PATCH 06/12] perf tools: Keep zero in pgoff bpf map Jiri Olsa
2019-05-03  8:18 ` [PATCH 07/12] perf script: Pad dso name for --call-trace Jiri Olsa
2019-05-06 21:38   ` Song Liu
2019-05-07  8:13     ` Jiri Olsa
2019-05-07 18:29       ` Song Liu
2019-05-08  7:40         ` Jiri Olsa
2019-05-03  8:18 ` Jiri Olsa [this message]
2019-05-03  8:18 ` [PATCH 09/12] perf tests: Add map_groups__merge_in test Jiri Olsa
2019-05-03  8:18 ` [PATCH 10/12] perf script: Add --show-bpf-events to show eBPF related events Jiri Olsa
2019-05-06 21:42   ` Song Liu
2019-05-07  8:18     ` Jiri Olsa
2019-05-07 18:27       ` Song Liu
2019-05-03  8:18 ` [PATCH 11/12] perf script: Remove superfluous bpf event titles Jiri Olsa
2019-05-03  8:18 ` [PATCH 12/12] perf script: Add --show-all-events option Jiri Olsa
2019-05-06 21:46 ` [PATCHv2 00/12] perf tools: Display eBPF code in intel_pt trace Song Liu
2019-05-08 13:19 [PATCHv3 " Jiri Olsa
2019-05-08 13:20 ` [PATCH 08/12] perf tools: Preserve eBPF maps when loading kcore Jiri Olsa
2019-05-22 16:06   ` Arnaldo Carvalho de Melo
2019-05-22 21:22     ` Jiri Olsa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190503081841.1908-9-jolsa@kernel.org \
    --to=jolsa@kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=sdf@fomichev.me \
    --cc=songliubraving@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.