All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>,
	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: Re: [PATCH 08/12] perf tools: Preserve eBPF maps when loading kcore
Date: Wed, 22 May 2019 23:22:59 +0200	[thread overview]
Message-ID: <20190522212259.GA11325@krava> (raw)
In-Reply-To: <20190522160657.GF30271@kernel.org>

On Wed, May 22, 2019 at 01:06:57PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, May 08, 2019 at 03:20:06PM +0200, Jiri Olsa escreveu:
> > We need to preserve eBPF maps even if they are
> > covered by kcore, because we need to access
> > eBPF dso for source data.
> 
> So, I reordered this one with the previous, as to get the output you
> added to 07/12 we need what is in 08/12, and they are otherwise
> completely independent, right?

right

jirka

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

  reply	other threads:[~2019-05-22 21:23 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08 13:19 [PATCHv3 00/12] perf tools: Display eBPF code in intel_pt trace Jiri Olsa
2019-05-08 13:19 ` [PATCH 01/12] perf tools: Separate generic code in dso__data_file_size Jiri Olsa
2019-05-13 19:47   ` Arnaldo Carvalho de Melo
2019-05-13 20:00     ` Jiri Olsa
2019-05-23  3:10       ` Namhyung Kim
2019-05-23  7:49         ` Jiri Olsa
2019-05-30  8:08   ` [tip:perf/core] perf dso: Separate generic code in dso__data_file_size() tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 02/12] perf tools: Separate generic code in dso_cache__read Jiri Olsa
2019-05-30  8:09   ` [tip:perf/core] perf dso: " tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 03/12] perf tools: Simplify dso_cache__read function Jiri Olsa
2019-05-30  8:09   ` [tip:perf/core] perf dso: " tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 04/12] perf tools: Add bpf dso read and size hooks Jiri Olsa
2019-05-30  8:10   ` [tip:perf/core] perf dso: Add BPF DSO " tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 05/12] perf tools: Read also the end of the kernel Jiri Olsa
2019-05-24 18:15   ` Arnaldo Carvalho de Melo
2019-05-24 18:17     ` Arnaldo Carvalho de Melo
2019-05-24 18:46       ` Arnaldo Carvalho de Melo
2019-05-26 13:09         ` Jiri Olsa
2019-05-24 23:21     ` Jiri Olsa
2019-05-28 21:29   ` [tip:perf/urgent] perf machine: " tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 06/12] perf tools: Keep zero in pgoff bpf map Jiri Olsa
2019-05-30  7:55   ` [tip:perf/core] perf machine: Keep zero in pgoff BPF map tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 07/12] perf script: Pad dso name for --call-trace Jiri Olsa
2019-05-30  8:11   ` [tip:perf/core] perf script: Pad DSO " tip-bot for 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 [this message]
2019-05-30  7:56   ` [tip:perf/core] " tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 09/12] perf tests: Add map_groups__merge_in test Jiri Olsa
2019-05-30  8:11   ` [tip:perf/core] " tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 10/12] perf script: Add --show-bpf-events to show eBPF related events Jiri Olsa
2019-05-30  8:12   ` [tip:perf/core] " tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 11/12] perf script: Remove superfluous bpf event titles Jiri Olsa
2019-05-30  8:13   ` [tip:perf/core] perf script: Remove superfluous BPF " tip-bot for Jiri Olsa
2019-05-08 13:20 ` [PATCH 12/12] perf script: Add --show-all-events option Jiri Olsa
2019-05-22 16:18   ` Arnaldo Carvalho de Melo
2019-05-22 21:30     ` Jiri Olsa
2019-05-08 21:49 ` [PATCHv3 00/12] perf tools: Display eBPF code in intel_pt trace Song Liu
2019-05-08 23:41   ` Arnaldo Carvalho de Melo
2019-05-24  0:27 ` Arnaldo Carvalho de Melo
2019-05-24 10:06   ` Jiri Olsa
2019-05-30 10:54 ` Leo Yan
2019-05-30 12:07   ` Jiri Olsa
2019-05-30 12:57     ` Leo Yan
2019-05-30 13:27       ` Jiri Olsa
2019-05-30 13:36       ` Arnaldo Carvalho de Melo
2019-05-30 14:05         ` Leo Yan
2019-05-31  9:19           ` Jiri Olsa
2019-06-02  6:42             ` Leo Yan
2019-05-31  9:09         ` Leo Yan
  -- strict thread matches above, loose matches on Subject: below --
2019-05-03  8:18 [PATCHv2 " Jiri Olsa
2019-05-03  8:18 ` [PATCH 08/12] perf tools: Preserve eBPF maps when loading kcore 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=20190522212259.GA11325@krava \
    --to=jolsa@redhat.com \
    --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=jolsa@kernel.org \
    --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.