linux-kernel - Re: [PATCH 02/13] perf hist: Save raw

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: <20151224011915.GO19926@kernel.org>
Date:	Wed, 23 Dec 2015 22:19:15 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Namhyung Kim <namhyung@...nel.org>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Jiri Olsa <jolsa@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	David Ahern <dsahern@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Andi Kleen <andi@...stfloor.org>,
	Wang Nan <wangnan0@...wei.com>
Subject: Re: [PATCH 02/13] perf hist: Save raw_data/size for tracepoint events

Em Thu, Dec 24, 2015 at 09:45:45AM +0900, Namhyung Kim escreveu:
> Hi Arnaldo,
> 
> On Wed, Dec 23, 2015 at 06:43:35PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Dec 23, 2015 at 02:06:59AM +0900, Namhyung Kim escreveu:
> > > The raw_data and raw_size fields are to provide tracepoint specific
> > > information.  They will be used by dynamic sort keys later.
> > > 
> > > Signed-off-by: Namhyung Kim <namhyung@...nel.org>
> > > ---
> > >  tools/perf/util/hist.c | 4 ++++
> > >  tools/perf/util/sort.h | 2 ++
> > >  2 files changed, 6 insertions(+)
> > > 
> > > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
> > > index 039bb91d0a92..c0c92a3daa69 100644
> > > --- a/tools/perf/util/hist.c
> > > +++ b/tools/perf/util/hist.c
> > > @@ -487,6 +487,8 @@ struct hist_entry *__hists__add_entry(struct hists *hists,
> > >  		.branch_info = bi,
> > >  		.mem_info = mi,
> > >  		.transaction = sample->transaction,
> > > +		.raw_data = sample->raw_data,
> > > +		.raw_size = sample->raw_size,
> > 
> > So, sample->raw_data is just a pointer to perf_event_sample->array, that
> > may be overwritten, no?
> 
> I couldn't find where the array data is overwritten.  The
> __perf_session__process_events() mmaps with PROT_READ basically.  But
> the mmap can be munmapped on 32 bit systems.  I'll keep a copy then.

perf top, aka mmap with overwrite mode? 

I think we should always think first at how to make such new features to
work on 'perf top', where there is no such thing as a "file", but a
_ring_ buffer, where we reuse that buffer when we fill it up, so we
should not keep any pointers to past events, just use what in the
currently being processed.

Haven't looked, do we need to access it after we add the hist, or just
after the perf_sample is parsed?

> > Looking at the other patches.
> 
> Thanks,
> Namhyung
> 
> > 
> > - Arnaldo
> > 
> > >  	};
> > >  
> > >  	return hists__findnew_entry(hists, &entry, al, sample_self);
> > > @@ -801,6 +803,8 @@ iter_add_next_cumulative_entry(struct hist_entry_iter *iter,
> > >  			.sym = al->sym,
> > >  		},
> > >  		.parent = iter->parent,
> > > +		.raw_data = sample->raw_data,
> > > +		.raw_size = sample->raw_size,
> > >  	};
> > >  	int i;
> > >  	struct callchain_cursor cursor;
> > > diff --git a/tools/perf/util/sort.h b/tools/perf/util/sort.h
> > > index 86f05e7a5566..d29898708dbd 100644
> > > --- a/tools/perf/util/sort.h
> > > +++ b/tools/perf/util/sort.h
> > > @@ -122,6 +122,8 @@ struct hist_entry {
> > >  	struct branch_info	*branch_info;
> > >  	struct hists		*hists;
> > >  	struct mem_info		*mem_info;
> > > +	void			*raw_data;
> > > +	u32			raw_size;
> > >  	struct callchain_root	callchain[0]; /* must be last member */
> > >  };
> > >  
> > > -- 
> > > 2.6.4
--
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/