All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Justin Mattock <justinmattock@gmail.com>,
	Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Frederic Weisbecker <fweisbec@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: system gets stuck in a lock during boot
Date: Tue, 6 Oct 2009 16:32:26 -0400	[thread overview]
Message-ID: <20091006203225.GC2631@redhat.com> (raw)
In-Reply-To: <1254792249.13160.213.camel@gandalf.stny.rr.com>

On Mon, Oct 05, 2009 at 09:24:09PM -0400, Steven Rostedt wrote:
> On Fri, 2009-10-02 at 17:12 -0400, Jason Baron wrote:
> 
> > hi Justin,
> > 
> > I've been playing around with gcc '4.5' as well and hit a panic that
> > looks very similar to what you've seen with stock 2.6.31 - I haven't
> > seen it anywhere else. Anyways, it seems to be some sort of alignment
> > issue with the 'struct ftrace_event_call'. I'm not sure yet if this is a
> > compiler or kernel issue. But the following kernel patch fixes the issue
> > for me. It would be interesting to verify if the patch also resolves the
> > issue for you.
> > 
> > thanks,
> > 
> > -Jason
> > 
> > 
> > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> > index 6ad76bf..0029af4 100644
> > --- a/include/asm-generic/vmlinux.lds.h
> > +++ b/include/asm-generic/vmlinux.lds.h
> > @@ -164,6 +164,7 @@
> >  	LIKELY_PROFILE()		       				\
> >  	BRANCH_PROFILE()						\
> >  	TRACE_PRINTKS()							\
> > +	. = ALIGN(32);							\
> >  	FTRACE_EVENTS()							\
> >  	TRACE_SYSCALLS()
> >  
> > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > index a81170d..43f9f1e 100644
> > --- a/include/linux/ftrace_event.h
> > +++ b/include/linux/ftrace_event.h
> > @@ -124,7 +124,7 @@ struct ftrace_event_call {
> >  	atomic_t		profile_count;
> >  	int			(*profile_enable)(struct ftrace_event_call *);
> >  	void			(*profile_disable)(struct ftrace_event_call *);
> > -};
> > +} __attribute__((aligned(32)));
> >  
> >  #define MAX_FILTER_PRED		32
> >  #define MAX_FILTER_STR_VAL	128
> > diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
> > index f64fbaa..4697fb6 100644
> > --- a/include/trace/ftrace.h
> > +++ b/include/trace/ftrace.h
> > @@ -600,7 +600,7 @@ static int ftrace_raw_init_event_##call(void)				\
> >  }									\
> >  									\
> >  static struct ftrace_event_call __used					\
> > -__attribute__((__aligned__(4)))						\
> > +__attribute__((__aligned__(32)))					\
> >  __attribute__((section("_ftrace_events"))) event_##call = {		\
> >  	.name			= #call,				\
> >  	.system			= __stringify(TRACE_SYSTEM),		\
> 
> Are all alignments needed? Or just adding one might help. Or removing
> the one directly above?
> 
> -- Steve
> 

So the problem I'm seeing is an oops on boot caused by the call->system pointer
deference in event_create_dir(). The 'call' variable is of type 'struct
ftrace_event_call'. 

What's going on is that the 'struct ftrace_event_call' is of size 168 bytes
(sizeof(struct ftrace_event_call)) = 168 = 0xA8. However, in memory the
structures are 16-byte aligned. Thus, the stride for walking through the
pointers needs to be 176 (0xB0), but instead its 168 causing the oops.

I've only seen this issue while using gcc (GCC) 4.5.0 20090916, on a
vanilla 2.6.31 kernel.

That said, I'm not sure the compiler is doing the wrong thing here. The
'struct ftrace_event_call' contains an embedded 'struct list_head' which
is 16 bytes. According to the gcc docs, the aligned attribute, 'specifies a
minimum alignment for the variable or structure field, measured in bytes'.
Thus, at least according to the docs, gcc can increase the alignment of the
'struct ftrace_event_call', from its original specification of 4, to 16. Even
in the case where we are working corectly the structures are 8-byte aligned.

Thus, I would reccommend the patch below as a preventive measure. Its
the minimal patch I've found to resolve this issue. In general, if we
are going to walk data structures embedded in a special elf section, I
think the general rules needs to be to set the alignment to the power of
two which is greater than or equal to the largest item in the structure.

thanks,

-Jason

Signed-off-by: Jason Baron <jbaron@redhat.com>


diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
index a81170d..7182f03 100644
--- a/include/linux/ftrace_event.h
+++ b/include/linux/ftrace_event.h
@@ -124,7 +124,10 @@ struct ftrace_event_call {
 	atomic_t		profile_count;
 	int			(*profile_enable)(struct ftrace_event_call *);
 	void			(*profile_disable)(struct ftrace_event_call *);
-};
+} __attribute__((aligned(16)));
+
+/* Align to the largest field in the data structure:
+ * sizeof(struct list_head) = 16 */
 
 #define MAX_FILTER_PRED		32
 #define MAX_FILTER_STR_VAL	128
diff --git a/include/trace/ftrace.h b/include/trace/ftrace.h
index f64fbaa..e344e81 100644
--- a/include/trace/ftrace.h
+++ b/include/trace/ftrace.h
@@ -600,7 +600,6 @@ static int ftrace_raw_init_event_##call(void)				\
 }									\
 									\
 static struct ftrace_event_call __used					\
-__attribute__((__aligned__(4)))						\
 __attribute__((section("_ftrace_events"))) event_##call = {		\
 	.name			= #call,				\
 	.system			= __stringify(TRACE_SYSTEM),		\




  reply	other threads:[~2009-10-06 20:34 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
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 [this message]
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=20091006203225.GC2631@redhat.com \
    --to=jbaron@redhat.com \
    --cc=fweisbec@gmail.com \
    --cc=justinmattock@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.