Re: [PATCH 2/2] arm: make return_address available for ARM_UNWIND

From: Keun-O Park
Date: Fri Jan 04 2013 - 03:46:04 EST

On Fri, Jan 4, 2013 at 1:58 AM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> On Thu, 2013-01-03 at 16:23 +0000, Russell King - ARM Linux wrote:
>> On Thu, Jan 03, 2013 at 11:03:58AM -0500, Steven Rostedt wrote:
>> > On Thu, 2013-01-03 at 14:13 +0000, Russell King - ARM Linux wrote:
>> > > In summary, from what I can see in the patch, the reason why the ifdefs
>> > > are the way they are, and the reason the warning is there has not been
>> > > addressed; these patches just seem to be aimed just at removing a #warning
>> > > statement to make the warning go away.
>> >
>> > You're correct that this patch does not solve any of theses issues. Now,
>> > I'm thinking that ftrace has matured where these issues don't exist, and
>> > where they do, it will only cause noise in the trace than anything
>> > serious. But, this needs to be looked deeper to make sure.
>> Looking back in the archives, it seems that we had a problem with ftrace
>> and the unwinder polluting the trace information:
>> There's quite a bit of discussion in that thread about this which details
>> why we came up with what we have today.
> Thanks for the link. In fact, I see I was even involved :-)
> Just as I explained, the problem isn't a recursion bug, but just noise
> in the trace.
> Some of what is called by unwind_frame() will always be traced, and I
> wouldn't want 'notrace' annotation on those.
> If anything, I would just suggest another config option that lets the
> user decide if they don't mind the messiness of the trace for the added
> benefit of where the latency output came from.
> Also, it's rather trivial to make the entire unwind.c not traced, by
> adding in the Makefile:
> CFLAGS_REMOVE_unwind.o = -pg
> But that only stops the tracing of the unwind_*. Looks to be a lot of
> those. But it wont stop the tracing of:
> kernel_text_address <-unwind_frame
> core_kernel_text <-unwind_frame
> search_index <-unwind_frame
> etc.
> Heck, the user could just keep those from being traced by doing:
> echo kernel_text_address core_kernel_text search_index > \
> /sys/kernel/debug/tracing/set_ftrace_notrace
> If DYNAMIC_FTRACE is defined.
> -- Steve

With "CFLAGS_REMOVE_unwind.o = -pg" and with CONFIG_PROVE_LOCKING
turned on, I confirmed that
there's no trace output like Steve mentioned.
However, if I turn off CONFIG_PROVE_LOCKING, "irqsoff" and
"preemptirqsoff" ftracer prints these lines :

kernel_text_address <-unwind_frame
core_kernel_text <-unwind_frame
search_index <-unwind_frame

While I investigated the reason, I just found out there's two function
with same name, trace_hardirqs_off.
One in kernel/trace/trace_irqsoff.c and another in kernel/lockdep.c.
And both symbols are exported.
I am wondering whether it is intentionally maintained code to
manipulate ftrace and lockdep or not.
I guess it's probably not.

-- Kpark
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at