All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Marc Kleine-Budde <mkl@pengutronix.de>
Cc: linux-kernel@vger.kernel.org,
	"Steven Rostedt (Red Hat)" <rostedt@goodmis.org>,
	ptx kernel <kernel@pengutronix.de>
Subject: Re: dynamic ftrace/recordmcount.c problem on ARMv5
Date: Fri, 11 Mar 2016 10:21:59 +0100	[thread overview]
Message-ID: <20160311092159.GA1781@pengutronix.de> (raw)
In-Reply-To: <56961010.6000806@pengutronix.de>

Hello,

On Wed, Jan 13, 2016 at 09:51:28AM +0100, Marc Kleine-Budde wrote:
> Hello,
> 
> I'm on a ARMv5 (freescale mx25) and seeing this ftrace bug during bootup:
> 
> > [    0.059235] ------------[ cut here ]------------
> > [    0.059449] WARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:1938 ftrace_bug+0x210/0x2c8()
> > [    0.059645] Modules linked in:
> > [    0.059780] CPU: 0 PID: 0 Comm: swapper Not tainted 4.0.9-20151211-1-g45dbe7d2c077 #1
> > [    0.059966] Hardware name: Freescale i.MX25 (Device Tree Support)
> > [    0.060157] [<8000f494>] (unwind_backtrace) from [<8000ce3c>] (show_stack+0x20/0x24)
> > [    0.060396] [<8000ce3c>] (show_stack) from [<8041ea68>] (dump_stack+0x20/0x28)
> > [    0.060630] [<8041ea68>] (dump_stack) from [<8001a74c>] (warn_slowpath_common+0x88/0xc0)
> > [    0.060853] [<8001a74c>] (warn_slowpath_common) from [<8001a840>] (warn_slowpath_null+0x2c/0x34)
> > [    0.061091] [<8001a840>] (warn_slowpath_null) from [<80083748>] (ftrace_bug+0x210/0x2c8)
> > [    0.061332] [<80083748>] (ftrace_bug) from [<80083bb8>] (ftrace_process_locs+0x330/0x6f0)
> > [    0.061576] [<80083bb8>] (ftrace_process_locs) from [<805bdc84>] (ftrace_init+0x8c/0x14c)
> > [    0.061815] [<805bdc84>] (ftrace_init) from [<805b0c80>] (start_kernel+0x33c/0x3b4)
> > [    0.062039] [<805b0c80>] (start_kernel) from [<80008040>] (0x80008040)
> > [    0.062238] ---[ end trace cb88537fdc8fa200 ]---
> > [    0.062364] ftrace failed to modify [<8000c7d8>] walk_stackframe+0x24/0x44
> > [    0.062544]  actual: 16:ff:2f:e1
> > [    0.062702] ftrace record flags: 0
> > [    0.062803]  (0)   expected tramp: 8000e864
> 
> The problem is that walk_stackframe ends up in the __mcount_loc section,
> although it has a "notrace" attribute:

Not having much clue about elf and stuff, but being hit by this problem
I added some debug output to recordmcount.c and found that
sift_rel_mcount (aka sift32_rel_mcount) loops over .rel.text which looks
as follows for me:

	$ readelf -R .rel.text arch/arm/kernel/stacktrace.o 
	...
	Relocation section '.rel.text' at offset 0xb5c contains 15 entries:
	 Offset     Info    Type            Sym.Value  Sym. Name
	0000001c  00000028 R_ARM_V4BX       
	0000002c  00001d1c R_ARM_CALL        00000000   unwind_frame
	00000044  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
	00000104  0000201c R_ARM_CALL        00000000   in_sched_functions
	00000118  00002102 R_ARM_ABS32       00000000   __exception_text_start
	0000011c  00002202 R_ARM_ABS32       00000000   __exception_text_end
	00000130  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
	00000194  00001c1c R_ARM_CALL        00000000   walk_stackframe
	000001e0  00000902 R_ARM_ABS32       0000003c   save_trace
	000001e4  00000c02 R_ARM_ABS32       00000120   __save_stack_trace
	000001ec  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
	00000218  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
	00000260  00001c1c R_ARM_CALL        00000000   walk_stackframe
	0000028c  00000902 R_ARM_ABS32       0000003c   save_trace
	00000294  00001f1c R_ARM_CALL        00000000   __gnu_mcount_nc
	...

and the unwanted entry in __mcount_loc is generated from the first line
which isn't a call, but just the information that there is a bx call
that needs a fixup for ARMv4 machines (that don't support the bx
instruction).

For this entry get_mcountsym returns 0.

recordmcount.pl only operates on R_ARM_(CALL|PC24|THM_CALL) types for
ARM and so does it right.

I don't know how to fix recordmcount.[ch], but maybe this is enough info
to allow someone more knowledgeable to fix it.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

  parent reply	other threads:[~2016-03-11  9:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13  8:51 dynamic ftrace/recordmcount.c problem on ARMv5 Marc Kleine-Budde
2016-01-13 16:08 ` Steven Rostedt
2016-01-13 16:23   ` Marc Kleine-Budde
2016-01-13 16:27     ` Steven Rostedt
2016-01-13 16:30       ` Marc Kleine-Budde
2016-02-08 15:38 ` Marc Kleine-Budde
2016-02-08 15:53   ` Steven Rostedt
2016-03-11  9:21 ` Uwe Kleine-König [this message]
2016-03-20  3:48   ` Namhyung Kim
2016-03-20 20:00     ` Uwe Kleine-König

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=20160311092159.GA1781@pengutronix.de \
    --to=u.kleine-koenig@pengutronix.de \
    --cc=kernel@pengutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkl@pengutronix.de \
    --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.