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:	Fri, 14 Nov 2008 15:39:29 +0100
From:	"Frédéric Weisbecker" <fweisbec@...il.com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Cc:	rostedt@...dmis.org, mingo@...e.hu, akpm@...ux-foundation.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] ftrace: Add debug_print trace to print data from kernel to userspace

2008/11/14 Aneesh Kumar K.V <aneesh.kumar@...ux.vnet.ibm.com>:
> We also want to make sure dp_printk doesn't do anything when tracer
> is disabled. We do
>
> int do_dp_printk(const char *fmt, ...)
> {
>        int ret;
>        va_list args;
>
>        if (!tracer_enabled)
>                return 0;


In this case you just have to do
echo 0 > /debug/tracing/tracing_enabled
And the entries will not be printed anymore....

> .........
> .......
>
>>
>>
>>
>> > +static void dp_trace_ctrl_update(struct trace_array *tr)
>> > +{
>> > +       /* When starting a new trace, reset the buffers */
>> > +       if (tr->ctrl)
>> > +               start_dp_trace(tr);
>> > +       else
>> > +               stop_dp_trace(tr);
>> > +}
>>
>>
>> BTW, ctrl_update() have been removed very recently.
>> Perhaps are you implementing this against the mainline? Its a better idea to
>> submit a new tracer against latest -tip tree.
>
> Yes the patches are against mainline.


> I am looking at this. I don't see TRACE_TYPE_PARTIAL_LINE in other
> places in the code. Will look more.


This return has been set because several entries can be submitted to a
tracer before it finally reach the user.
If the last one submitted didn't fir is the remaining free bytes in
the seq, then we want to tell the tracing api that
the seq is full and we want this entry to be handled later.
If you don't use it, you could loose entries.
Have a look in trace.c, trace_boot.c, trace_mmiotrace.c, all of these
make use of this return value.

See latest -tip:
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git


> What I wanted to get was a dmesg style output. The default output will
> add pid and other information. That is why i did a print_line callback.


I understand...
Why not append a flag to ignore pid/cpu/timestamp on the output in trace.c ?

> I also wanted to drop the header in the trace file.  I didn't find a way
> to do that.


This one should be dropped too when the flag I mentioned above is set....
Currently, when one cat /debug/tracing/trace, we have these headers,
whatever the current tracer is.
This thing could be fixed...

Perhaps others would have better ideas....
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ