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
| ||
|
Message-ID: <1410885227.12376.20.camel@hornet> Date: Tue, 16 Sep 2014 17:33:47 +0100 From: Pawel Moll <pawel.moll@....com> To: Arnaldo Carvalho de Melo <acme@...nel.org> Cc: Christopher Covington <cov@...eaurora.org>, Richard Cochran <richardcochran@...il.com>, Steven Rostedt <rostedt@...dmis.org>, Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>, Paul Mackerras <paulus@...ba.org>, John Stultz <john.stultz@...aro.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "linux-api@...r.kernel.org" <linux-api@...r.kernel.org> Subject: Re: [RFC 2/2] perf: Marker software event and ioctl On Mon, 2014-09-15 at 19:31 +0100, Arnaldo Carvalho de Melo wrote: > Em Mon, Sep 15, 2014 at 06:27:14PM +0100, Pawel Moll escreveu: > > On Fri, 2014-09-12 at 17:19 +0100, Arnaldo Carvalho de Melo wrote: > > > Em Fri, Sep 12, 2014 at 02:58:55PM +0100, Pawel Moll escreveu: > > > > On Fri, 2014-09-12 at 14:49 +0100, Arnaldo Carvalho de Melo wrote: > > > > > Perhaps both? I.e. an u64 followed from a string, if the u64 is zero, > > > > > then there is a string right after it? > > > > > > > How would this look like in userspace? Something like this? > > > > > > > 8<---- > > > > struct perf_event_marker { > > > > uint64_t value; > > > > char *string; > > > > } arg; > > > > > > > arg.value = 0x1234; > > > > > > > /* or */ > > > > > > > arg.value = 0; > > > > arg.string = "abcd"; > > > > > > > ioctl(fd, PERF_EVENT_IOC_MARKER, &arg) > > > > 8<---- > > > > > > > If so, maybe it would simpler just to go for classic size/data > > > > structure? > > > > > > > 8<----- > > > > struct perf_event_marker { > > > > uint32_t size; > > > > void *data; > > > > } > > > > 8<----- > > > > > > > This would directly map into struct perf_raw_record... > > > > > > I can see the usefulness of having it all, i.e. if we do just: > > > > > > perf trace --pid `pidof some-tool-in-debug-mode-using-this-interface` > > > > Hm. I haven't thought about a situation when 3rd party wants to inject > > something into "my" data stream... I guess it could be implemented (a > > I was thinking about intercepting calls that pass some logging data, as > strings, and 'tee' them to the 'perf trace' 'data stream'. Right, ok, like LD_PRELOADing printf (a stupid example of course) and piping it inside perf... So if I'm getting it right, it's the perf process that would eventually do the ioctl(PERF_EVENT_IOC_MARKER), not the traced process, correct? This makes sense. Another use case for ioctl justification, thanks :-) > > "myself"?), but will definitely complicate the patch. Should I have a > > look at it now or maybe leave it till we get a general agreement about > > the marker ioctl existence? > > > > > Then 'perf trace' doesn't know about any binary format a tool may have, > > > getting strings there (hey, LD_PRELOADing some logging library to hook > > > into this comes to mind) and having it merged with other events > > > (syscalls, pagefaults, etc) looks useful. > > > > But do you still mean a "magic" u64 before the rest? Injecting a string > > would just mean: > > > > marker.size = strlen(s) + 1; > > marker.data = s; > > > > > As well as some specialized version of 'perf trace' that knows about > > > some binary protocol that would get app specific stats or lock status, > > > etc, perhaps even plugins for 'perf trace' that would be selected by > > > that first u64? Also seems useful. > > > > > > I.e. having a way to provide just strings and another that would allow > > > passing perf_raw_record. > > > > Sounds interesting. But then maybe this stuff shouldn't go into "raw" > > then? It could be something like this in the sample: > > > > { u64 type; /* 0 means zero-terminated string in data */ > > u32 size; > > char data[size]; } && PERF_SAMPLE_MARKER > > Yes, this is how I think it should be. Seems that Ingo had exactly the same thing on mind. I'll get a patch done. Paweł -- 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/
Powered by blists - more mailing lists