linux-kernel - Re: [RFC PATCH] Kernel Tracepoints

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] [day] [month] [year] [list]

Message-ID: <486D1FCC.5040205@redhat.com>
Date:	Thu, 03 Jul 2008 14:51:56 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
CC:	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Takashi Nishiie <t-nishiie@...css.fujitsu.com>,
	"'Alexey Dobriyan'" <adobriyan@...il.com>,
	"'Peter Zijlstra'" <peterz@...radead.org>,
	"'Steven Rostedt'" <rostedt@...dmis.org>,
	"'Frank Ch. Eigler'" <fche@...hat.com>,
	"'Ingo Molnar'" <mingo@...e.hu>,
	"'LKML'" <linux-kernel@...r.kernel.org>,
	"'systemtap-ml'" <systemtap@...rces.redhat.com>,
	"'Hideo AOKI'" <haoki@...hat.com>
Subject: Re: [RFC PATCH] Kernel Tracepoints

Hi Mathieu,

Mathieu Desnoyers wrote:
> * Masami Hiramatsu (mhiramat@...hat.com) wrote:
>> Hi Mathieu,
>>
>> Mathieu Desnoyers wrote:
>>> * Masami Hiramatsu (mhiramat@...hat.com) wrote:
>>>> Mathieu Desnoyers wrote:
>>>>> * Masami Hiramatsu (mhiramat@...hat.com) wrote:
>>>>>  >
>>>>>>> Implementation of kernel tracepoints. Inspired from the Linux Kernel Markers.
>>>>>> What would you think redesigning markers on tracepoints? because most of the
>>>>>> logic (scaning sections, multiple probe and activation) seems very similar
>>>>>> to markers.
>>>>>>
>>>>> We could, although markers, because they use var args, allow to put the
>>>>> iteration on the multi probe array out-of-line. Tracepoints cannot
>>>>> afford this and the iteration must be done at the initial call-site.
>>>>>
>>>>> From what I see in your proposal, it's mostly to extract the if() call()
>>>>> code from the inner __trace_mark() macro and to put it in a separate
>>>>> macro, am I correct ? This would make the macro more readable.
>>>> Sure, I think marker and tracepoint can share below functions;
>>>> - definition of static local variables in specific sections
>>> Given that we could want to keep activation of tracepoints and markers
>>> separate (so they don't share the same namespace), declaring the static
>>> variables in separated sections seems to make sense to me.
>> Sorry, I'm not sure what is "separate activation".
>> As far as I can see, both tracepoints and markers are activated
>> when its probe handlers are registered on each tracepoint/marker.
>> Aren't it separated?
>>
> 
> Yes, it is separate. This is insured by the fact that markers and
> tracepoints are declared in different sections. Therefore, even if they
> have the same "name", they won't be used by each other.

I reviewed both marker and tracepoint deeply in these days, and
recognized what you said. Actually, markers and tracepoint would
better have separate sections.

[...]
>>>> - probe activation code (if() call())
>>>> - multi probe handling
>>> Hrm, the thing here is that because markers allow to do the iteration on
>>> the multiple probe callbacks within an internal wrapper (instead of
>>> doing it on-site as in the tracepoints), it allows to do some further
>>> optimizations (less memory allocation and less pointer dereference in
>>> the single probe case, not having to prepare the va_args in the
>>> MARK_NOARGS case) which are only done because it does not have to add
>>> code to the instrumentation site. However, tracepoints cannot have such
>>> "generic" wrapper and we have to do the iteration on callbacks in the
>>> code added to the instrumented object. Therefore, I keep it as small as
>>> possible in terms of bytes of instructions.
>> OK, I see. So, __tracepoint_block() macro can specify handler function.
>> what would you think about it?
>>
> 
> When I originally designed the markers, I tried to make sure there was
> absolutely no code duplication until I discovered that trying to read a
> huge amount of nested macros is just a pain starting from a certain
> level. If we only save a few duplicated lines but end up tying up
> markers and tracepoints, I am far from certain that it will make the
> code more readable.

After reviewing, I knew it is hard to implement markers on tracepoint.
maybe, I need to find another way or maintenance both codes.


> I'll post a tracepoint version with the modifications you proposed (it's
> now placed earlier in the patchset), except the merge with markers.

I see, if it is acceptable for upstream developers, I have no problem.

Thank you,

-- 
Masami Hiramatsu

Software Engineer
Hitachi Computer Products (America) Inc.
Software Solutions Division

e-mail: mhiramat@...hat.com

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