linux-kernel - Re: [RFC PATCH 3/3] kernel tracing prototype

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, 2 Dec 2008 21:30:05 -0800
From:	Jiaying Zhang <jiayingz@...gle.com>
To:	Steven Rostedt <srostedt@...hat.com>
Cc:	linux-kernel@...r.kernel.org, Michael Rubin <mrubin@...gle.com>,
	Martin Bligh <mbligh@...gle.com>,
	Michael Davidson <md@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 3/3] kernel tracing prototype

On Tue, Dec 2, 2008 at 8:35 PM, Steven Rostedt <srostedt@...hat.com> wrote:
>
> On Tue, 2008-12-02 at 16:26 -0800, Jiaying Zhang wrote:
>> Refer to the previous email
>> "[RFC PATCH 0/3] A couple of feature requests to the unified trace
>> buffer".
>>
>> A kernel tracing prototype that uses the unified trace buffer to keep
>> the collected trace data.
>>
>
>> Index: linux-2.6.26.2/include/linux/ktrace.h
>> ===================================================================
>> --- /dev/null   1970-01-01 00:00:00.000000000 +0000
>> +++ linux-2.6.26.2/include/linux/ktrace.h       2008-11-25
>> 11:32:37.000000000 -0800
>> @@ -0,0 +1,73 @@
>> +#ifndef _LINUX_KTRACE_H
>> +#define _LINUX_KTRACE_H
>> +
>> +#include <linux/types.h>
>> +
>> +struct kernel_trace;
>> +
>> +typedef void ktrace_probe_func(struct kernel_trace *, void *,
>> size_t);
>> +
>> +struct kernel_trace {
>> +       const char      *name;
>> +       const char      *format;  /* format string describing variable
>> list */
>> +       u32             enabled:1, event_id:31;
>> +       ktrace_probe_func *func;  /* probe function */
>> +       struct list_head list;  /* list head linked to the hash table
>> entry */
>> +} __attribute__((aligned(8)));
>> +
>> +extern int ktrace_enabled;
>> +
>> +/*
>> + * Make sure the alignment of the structure in the __ktrace section
>> will
>> + * not add unwanted padding between the beginning of the section and
>> the
>> + * structure. Force alignment to the same alignment as the section
>> start.
>> + */
>> +
>> +#define DEFINE_KTRACE_STRUCT(name)     struct ktrace_struct_##name
>> +
>> +#ifdef CONFIG_KTRACE
>> +#define DO_TRACE(name, format, args...)
>>            \
>> +       do {
>>    \
>> +               static const char __kstrtab_##name[]
>>    \
>> +               __attribute__((section("__ktrace_strings")))
>>    \
>> +               = #name "\0" format;
>>    \
>> +               static struct kernel_trace __ktrace_##name
>>    \
>> +               __attribute__((section("__ktrace"), aligned(8))) =
>>    \
>> +               { __kstrtab_##name, &__kstrtab_##name[sizeof(#name)],
>> \
>> +               0, 0, NULL, LIST_HEAD_INIT(__ktrace_##name.list) };
>> \
>> +               __ktrace_check_format(format, ## args);
>> \
>> +               if (unlikely(ktrace_enabled) &&
>> \
>> +                               unlikely(__ktrace_##name.enabled))
>> {    \
>> +                       struct ktrace_struct_##name karg = { args };
>>    \
>> +                       (*__ktrace_##name.func)
>> \
>> +                       (&__ktrace_##name, &karg, sizeof(karg));
>>    \
>> +               }
>> \
>
> This looks like another form of markers/trace-points.  Why not use them?
Yes. It borrows many ideas from the marker code. But we don't intend
to be as general as markers and lttng, which allows us to make many
simplifications and we think will give us performance benefits.

Jiaying
>
>> +       } while (0)
>> +
>> +#else /* !CONFIG_KTRACE */
>> +#define DO_TRACE(name, format, args...)
>> +#endif
>> +
>
> -- Steve
>
>
>
--
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/