linux-kernel - Re: [PATCH V3 1/4] perf: Add PERF_RECORD

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]

Date:	Tue, 7 Jul 2015 13:13:59 -0300
From:	Arnaldo Carvalho de Melo <acme@...nel.org>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Adrian Hunter <adrian.hunter@...el.com>,
	Andi Kleen <ak@...ux.intel.com>,
	Ingo Molnar <mingo@...nel.org>, linux-kernel@...r.kernel.org,
	Jiri Olsa <jolsa@...hat.com>,
	Stephane Eranian <eranian@...gle.com>,
	mathieu.poirier@...aro.org, Pawel Moll <pawel.moll@....com>
Subject: Re: [PATCH V3 1/4] perf: Add PERF_RECORD_SWITCH to indicate context
 switches

Em Tue, Jul 07, 2015 at 05:36:14PM +0200, Peter Zijlstra escreveu:
> On Tue, Jul 07, 2015 at 10:44:37AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Jul 07, 2015 at 10:25:52AM -0300, Arnaldo Carvalho de Melo escreveu:
> > > Em Tue, Jul 07, 2015 at 11:36:39AM +0300, Adrian Hunter escreveu:
> > > > +	 * Records a context switch in or out (flagged by
> > > > +	 * PERF_RECORD_MISC_SWITCH_OUT).  next_prev_pid and next_prev_tid are
> > > > +	 * (u32)-1 unless the context is cpu-wide, in which case they are the

> > > Why carry those extra 8 bytes for non priviledged users, all the time
> > > with -1?

> > > Can't userspace cope with this, i.e. we should be able to look for those
> > > fields when the context is CPU wide, and to not look for them otherwise,
> > > no?

> > To help userspace in places where all it has is the union perf_event, we
> > can reuse one bit in misc to state that, i.e.

> >   #define PERF_RECORD_MISC_SWITCH_NEXT_PREV_PID 14

> > For instance.

> The other option would be a separate RECORD type, which might be
> simpler.

Humm, do we really need it?

I think this is just us wanting to, since we are going to add a new
record, to make it more useful for other, not right now needed,
situations, i.e. if the user is priviledged, there are two other options
to get his info, right?

So, yeah, since we have those bits doing nothing in header.misc, we
could well use them :-)

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