From: Li Zefan <lizf@cn.fujitsu.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
Andrew Morton <akpm@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Steven Rostedt <srostedt@redhat.com>
Subject: Re: [PATCH 2/6] tracing: increase size of number of possible events
Date: Fri, 24 Apr 2009 14:02:47 +0800 [thread overview]
Message-ID: <49F15607.1090707@cn.fujitsu.com> (raw)
In-Reply-To: <20090424043111.983189535@goodmis.org>
> From: Steven Rostedt <srostedt@redhat.com>
>
> With the new event tracing registration, we must increase the number
> of events that can be registered. Currently the type field is only
> one byte, which leaves us only 256 possible events.
>
> Since we do not save the CPU number in the tracer anymore (it is determined
> by the per cpu ring buffer that is used) we have an extra byte to use.
>
> This patch increases the size of type from 1 byte (256 events) to
> 2 bytes (65,536 events).
>
You forgot to change this:
@@ -198,7 +198,7 @@ ftrace_define_fields_##call(void) \
struct ftrace_event_call *event_call = &event_##call; \
int ret; \
\
- __common_field(int, type); \
+ __common_field(unsigned short, type); \
And we can apply the check in 3/6 to __common_field(). :)
> It also adds a WARN_ON_ONCE if we exceed that limit.
>
WARN_ON_ONCE() may not be sufficient IMO:
We can reach 65536 this way (It took me 15 mins):
while (foo_bar.id < 65536) {
insmod trace-events-sample.ko
rmmod trace-events-sample.ko
}
Now next id will be 0! Then do this:
console 1:
# cat /debug/tracing/trace_pipe
console 2:
while (1) {
insmod trace-events-sample.ko
echo foo_bar > /debug/tracing/set_event
rmmod trace-events-sample.ko
}
I got this immediately:
BUG: unable to handle kernel NULL pointer dereference at 0000006f
IP: [<c05210f3>] bstr_printf+0x2ce/0x302
...
Call Trace:
[<c0476d12>] ? trace_seq_bprintf+0x28/0x41
[<c0477569>] ? trace_bprint_print+0x58/0x6c
[<c0472ffc>] ? print_trace_line+0x2c5/0x2df
[<c0428a41>] ? sub_preempt_count+0x85/0xa0
[<c04758cf>] ? tracing_read_pipe+0x118/0x191
[<c04757b7>] ? tracing_read_pipe+0x0/0x191
[<c04b09f9>] ? vfs_read+0x8f/0x136
[<c04b0da3>] ? sys_read+0x40/0x65
[<c0402a68>] ? sysenter_do_call+0x12/0x36
(We can even get other crashes..)
So I think we should fail the initialization of the event, instead of
WARN_ON().
> @@ -537,6 +537,8 @@ int register_ftrace_event(struct trace_event *event)
> out:
> mutex_unlock(&trace_event_mutex);
>
> + WARN_ON_ONCE(next_event_type > FTRACE_MAX_EVENT);
> +
This WARN_ON is triggered when we create an event with id == 65535,
but not 65536.
next prev parent reply other threads:[~2009-04-24 6:02 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-24 4:30 [PATCH 0/6] [GIT PULL] x86,ring_buffer,tracing: updates for tip Steven Rostedt
2009-04-24 4:30 ` [PATCH 1/6] tracing/wakeup: move access to wakeup_cpu into spinlock Steven Rostedt
2009-04-24 4:30 ` [PATCH 2/6] tracing: increase size of number of possible events Steven Rostedt
2009-04-24 6:02 ` Li Zefan [this message]
2009-04-24 7:09 ` Ingo Molnar
2009-04-24 12:29 ` Steven Rostedt
2009-04-24 12:27 ` Steven Rostedt
2009-04-24 14:04 ` Steven Rostedt
2009-04-24 14:05 ` Steven Rostedt
2009-04-26 6:53 ` Li Zefan
2009-04-26 13:44 ` Steven Rostedt
2009-05-04 9:05 ` Li Zefan
2009-05-04 14:12 ` Steven Rostedt
2009-05-05 1:32 ` Li Zefan
2009-05-07 9:19 ` [tip:tracing/core] tracing: reset ring buffer when removing modules with events tip-bot for Steven Rostedt
2009-04-24 7:12 ` [PATCH 2/6] tracing: increase size of number of possible events Ingo Molnar
2009-04-24 12:30 ` Steven Rostedt
2009-04-24 4:30 ` [PATCH 3/6] tracing: add size checks for exported ftrace internal structures Steven Rostedt
2009-04-24 4:30 ` [PATCH 4/6] x86: use native register access for native tlb flushing Steven Rostedt
2009-04-24 4:30 ` [PATCH 5/6] tracing: fix cut and paste macro error Steven Rostedt
2009-04-24 4:30 ` [PATCH 6/6] ring_buffer: compressed event header Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49F15607.1090707@cn.fujitsu.com \
--to=lizf@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=srostedt@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox