linux-kernel - Re: [PATCH v1 4/6] perf: Allow using AUX data in perf samples

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: <20180619105151.w3hoymzmme57chzv@um.fi.intel.com>
Date:   Tue, 19 Jun 2018 13:51:51 +0300
From:   Alexander Shishkin <alexander.shishkin@...ux.intel.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>,
        linux-kernel@...r.kernel.org, jolsa@...hat.com
Subject: Re: [PATCH v1 4/6] perf: Allow using AUX data in perf samples

On Thu, Jun 14, 2018 at 09:39:17PM +0200, Peter Zijlstra wrote:
> On Thu, Jun 14, 2018 at 09:25:13PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 12, 2018 at 10:51:15AM +0300, Alexander Shishkin wrote:
> > > @@ -882,6 +890,7 @@ struct perf_sample_data {
> > >  	 */
> > >  	u64				addr;
> > >  	struct perf_raw_record		*raw;
> > > +	struct perf_aux_record		aux;
> > >  	struct perf_branch_stack	*br_stack;
> > >  	u64				period;
> > >  	u64				weight;
> > > @@ -933,6 +942,7 @@ static inline void perf_sample_data_init(struct perf_sample_data *data,
> > >  	/* remaining struct members initialized in perf_prepare_sample() */
> > >  	data->addr = addr;
> > >  	data->raw  = NULL;
> > > +	data->aux.from = data->aux.to = data->aux.size = 0;
> > >  	data->br_stack = NULL;
> > >  	data->period = period;
> > >  	data->weight = 0;
> > 
> > You just blew that cacheline...
> 
> And since the whole aux_sample thing seems to be purely prepare/output
> driven, I really don't see the need why this needs to be here. AFAICT it
> should just work fine in the other part of this structure.

Yes, this wasn't intentional. Will fix in the next round.

Regards,
--
Alex