linux-kernel - Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events

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: <545AD9C7.50205@redhat.com>
Date:	Wed, 05 Nov 2014 18:15:35 -0800
From:	Josh Stone <jistone@...hat.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
CC:	Namhyung Kim <namhyung@...nel.org>,
	Hemant Kumar <hemant@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org, srikar@...ux.vnet.ibm.com,
	peterz@...radead.org, oleg@...hat.com,
	hegdevasant@...ux.vnet.ibm.com, mingo@...hat.com,
	systemtap@...rceware.org, aravinda@...ux.vnet.ibm.com,
	penberg@....fi, Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace
 SDT events

On 11/05/2014 01:05 AM, Masami Hiramatsu wrote:
> [Off topic] I really don't like that the current SDT's semaphore. If the user apps
> see the instruction at the probe point, it is easy to check whether the event is
> enabled or not. Thus I recommend to change its implementation and update version
> instead of supporting current semaphore by perftools.

You and I have banged heads on this before, but I don't think checking
the instruction is a simple as you seem to think.  I invite you to
prototype this, and if you get it working we can discuss the tradeoffs.

The good news is that other tools (stap and gdb) won't need to care.  If
the SDT semaphore goes automatic, then we can just set that note field
to zero, unused from the tool's perspective.

Another tactic is to just discourage developers from using the semaphore
in the first place, as it's a completely optional feature.  The marker
is just a NOP, so adding some "if (enabled) {...}" around it is often a
useless load and branch.  It does make sense if the probe wants to
provide some expensively-computed arguments though, like cpython does to
prepare a function name string.  So if you see a project testing the
semaphore around simple arguments, I'd suggest they just probe directly
instead.

Thanks,
Josh
--
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/