public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.



  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