From: "Justin P. Mattock" <justinmattock@gmail.com>
To: Li Zefan <lizf@cn.fujitsu.com>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: system gets stuck in a lock during boot
Date: Sun, 23 Aug 2009 20:07:20 -0700 [thread overview]
Message-ID: <4A9203E8.307@gmail.com> (raw)
In-Reply-To: <4A91FDED.9050801@cn.fujitsu.com>
Li Zefan wrote:
> CC: Peter, Ingo
>
>
>> Hey alright 2.6.31-rc6 booted.
>>
>> I must admit, I've been afraid of doing
>> a git bisect for some time now. but after learning
>> to do a bisect, I cant see a better solution to finding a
>> bug(biggest issue I see is having a huge .config).
>>
>> Anyways the culprit for my issue is this commit:
>>
>> af6af30c0fcd77e621638e53ef8b176bca8bd3b4
>>
>> reverting this on rc6 booted the machine up.
>>
>>
>
> Thanks!
>
> Hmm...I don't see how this commit can cause oops:
>
same here, perf is not enabled at all.
before the git bisect I manually reverted all perf
and came to the conclusion the perf had nothing to do with this.
(must have missed this commit).
>
>> @@ -119,11 +119,9 @@ struct ftrace_event_call {
>> void *filter;
>> void *mod;
>>
>> -#ifdef CONFIG_EVENT_PROFILE
>> - atomic_t profile_count;
>> - int (*profile_enable)(struct ftrace_event_call *);
>> - void (*profile_disable)(struct ftrace_event_call *);
>> -#endif
>> + atomic_t profile_count;
>> + int (*profile_enable)(struct ftrace_event_call *);
>> + void (*profile_disable)(struct ftrace_event_call *);
>>
>
> In your .config, CONFIG_EVENT_PROFILE=y, so this change makes
> no difference.
>
>
>> };
>>
>> #define MAX_FILTER_PRED 32
>> diff --git a/kernel/trace/trace_event_profile.c b/kernel/trace/trace_event_profil
>> index 5b5895a..11ba5bb 100644
>> --- a/kernel/trace/trace_event_profile.c
>> +++ b/kernel/trace/trace_event_profile.c
>> @@ -14,7 +14,7 @@ int ftrace_profile_enable(int event_id)
>>
>> mutex_lock(&event_mutex);
>> list_for_each_entry(event,&ftrace_events, list) {
>> - if (event->id == event_id) {
>> + if (event->id == event_id&& event->profile_enable) {
>>
>
> You will run into this hunk only when you run the perf tool,
> so should have nothing to do with the boot failure.
>
I haven't really looked into perf yet, nor have it enabled.
>
>> ret = event->profile_enable(event);
>> break;
>> }
>> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
>> index 23d2972..e75276a 100644
>> --- a/kernel/trace/trace_events.c
>> +++ b/kernel/trace/trace_events.c
>> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentr
>> entry = trace_create_file("enable", 0644, call->dir, call,
>> enable);
>>
>> - if (call->id)
>> + if (call->id&& call->profile_enable)
>>
>
> We do an extra check on ->profile_enable, shouldn't cause bug..
>
maybe this has something to do with SELinux, since I saw with
the oops something with inode_do_init_dentry, and some other stuff
pertaining to SELinux(again though I'm lost as to why I'm hitting this).
>
>> entry = trace_create_file("id", 0444, call->dir, call,
>> id);
>>
>
> Any way, I don't think this commit does the right thing:
>
> - If CONFIG_EVENT_PROFILE=y, we'll create events/<dir>/<event>/id,
> except events/ftrace/<event>/id.
>
> - if CONFIG_EVENT_PROFILE=n, there's no 'id' file at all!
>
> I think it's better to skip ftrace/ dir in perf tool code, instead of
> skipping creating id files in ftrace code.
>
> can you try this patch:
>
> ---
> include/linux/ftrace_event.h | 2 ++
> kernel/trace/trace_events.c | 2 +-
> tools/perf/util/parse-events.c | 8 +++++++-
> 3 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> index a81170d..398c925 100644
> --- a/include/linux/ftrace_event.h
> +++ b/include/linux/ftrace_event.h
> @@ -121,9 +121,11 @@ struct ftrace_event_call {
> void *filter;
> void *mod;
>
> +#ifdef CONFIG_EVENT_PROFILE
> atomic_t profile_count;
> int (*profile_enable)(struct ftrace_event_call *);
> void (*profile_disable)(struct ftrace_event_call *);
> +#endif
> };
>
> #define MAX_FILTER_PRED 32
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index e75276a..23d2972 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -940,7 +940,7 @@ event_create_dir(struct ftrace_event_call *call, struct dentry *d_events,
> entry = trace_create_file("enable", 0644, call->dir, call,
> enable);
>
> - if (call->id&& call->profile_enable)
> + if (call->id)
> entry = trace_create_file("id", 0444, call->dir, call,
> id);
>
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index 0441784..1077ebd 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -113,13 +113,19 @@ static unsigned long hw_cache_stat[C(MAX)] = {
> [C(BPU)] = (CACHE_READ),
> };
>
> +static int is_tp_subsystem(struct dirent *sys_dir)
> +{
> + return !!strcmp(sys_dir->d_name, "ftrace");
> +}
> +
> #define for_each_subsystem(sys_dir, sys_dirent, sys_next, file, st) \
> while (!readdir_r(sys_dir,&sys_dirent,&sys_next)&& sys_next) \
> if (snprintf(file, MAXPATHLEN, "%s/%s", debugfs_path, \
> sys_dirent.d_name)&& \
> (!stat(file,&st))&& (S_ISDIR(st.st_mode))&& \
> (strcmp(sys_dirent.d_name, "."))&& \
> - (strcmp(sys_dirent.d_name, "..")))
> + (strcmp(sys_dirent.d_name, ".."))&& \
> + (is_tp_subsystem(&sys_dirent)))
>
> static int tp_event_has_id(struct dirent *sys_dir, struct dirent *evt_dir)
> {
>
>
>
>
Alright, in the morning I try this out and let you
know what happens.
Thanks for looking at this.
Justin P. Mattock
next prev parent reply other threads:[~2009-08-24 3:07 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-13 15:42 system gets stuck in a lock during boot Justin P. Mattock
2009-08-18 10:49 ` Frederic Weisbecker
2009-08-18 16:09 ` Steven Rostedt
2009-08-18 16:24 ` Justin Mattock
2009-08-18 19:57 ` Steven Rostedt
2009-08-18 20:06 ` Justin P. Mattock
2009-08-18 23:29 ` Steven Rostedt
2009-08-18 23:55 ` Justin P. Mattock
2009-08-19 0:23 ` Justin P. Mattock
2009-08-19 0:31 ` Steven Rostedt
2009-08-19 1:18 ` Justin P. Mattock
2009-08-19 1:10 ` Li Zefan
2009-08-20 5:51 ` Justin P. Mattock
2009-08-22 7:48 ` Justin P. Mattock
2009-08-24 2:41 ` Li Zefan
2009-08-24 3:07 ` Justin P. Mattock [this message]
2009-08-24 5:58 ` Peter Zijlstra
2009-08-24 6:13 ` Li Zefan
2009-08-24 6:49 ` Justin P. Mattock
2009-08-24 6:55 ` Peter Zijlstra
2009-08-24 7:54 ` Justin P. Mattock
2009-08-24 8:40 ` Justin P. Mattock
2009-08-24 19:19 ` Justin Mattock
2009-08-25 5:50 ` Peter Zijlstra
2009-08-25 6:04 ` Li Zefan
2009-08-25 6:21 ` Peter Zijlstra
2009-08-25 8:59 ` Ingo Molnar
2009-08-26 0:22 ` Justin P. Mattock
2009-08-26 7:33 ` Ingo Molnar
2009-08-26 14:42 ` Justin P. Mattock
2009-09-07 21:49 ` Justin Mattock
2009-10-02 21:12 ` Jason Baron
2009-10-04 17:41 ` Ingo Molnar
2009-10-05 0:10 ` Justin Mattock
2009-10-06 1:00 ` Justin P. Mattock
2009-10-06 1:18 ` Steven Rostedt
2009-10-06 2:01 ` Justin P. Mattock
2009-10-06 14:31 ` Jason Baron
2009-10-06 15:12 ` Justin P. Mattock
2009-10-06 1:24 ` Steven Rostedt
2009-10-06 20:32 ` Jason Baron
2009-10-06 22:30 ` Justin P. Mattock
2009-10-07 2:02 ` Steven Rostedt
2009-10-07 2:42 ` Justin P. Mattock
2009-10-07 13:00 ` Steven Rostedt
2009-10-07 14:53 ` Justin P. Mattock
2009-10-07 15:11 ` Steven Rostedt
2009-10-07 15:52 ` Justin P. Mattock
2009-10-07 16:06 ` Steven Rostedt
2009-10-07 17:47 ` Justin P. Mattock
2009-10-07 18:45 ` Justin P. Mattock
2009-10-07 18:55 ` Steven Rostedt
2009-10-07 19:08 ` Justin P. Mattock
2009-10-12 10:17 ` Ingo Molnar
2009-10-12 18:16 ` Justin P. Mattock
2009-10-07 14:30 ` Jason Baron
2009-10-07 14:40 ` Mathieu Desnoyers
2009-10-07 14:55 ` Steven Rostedt
2009-10-07 15:05 ` Mathieu Desnoyers
2009-10-07 15:14 ` Steven Rostedt
2009-08-24 19:42 ` Steven Rostedt
2009-08-24 23:34 ` Justin Mattock
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=4A9203E8.307@gmail.com \
--to=justinmattock@gmail.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizf@cn.fujitsu.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.