linux-kernel - Re: [PATCH 2/2] arm: make return_address available for ARM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 03 Jan 2013 11:58:57 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Keun-O Park <kpark3469@...il.com>, fweisbec@...il.com,
	mingo@...hat.com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, sahara <keun-o.park@...driver.com>
Subject: Re: [PATCH 2/2] arm: make return_address available for ARM_UNWIND

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:
> 
> http://lists.arm.linux.org.uk/lurker/message/20090604.201745.1c41ee6c.en.html
> 
> 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 :-)

http://lists.arm.linux.org.uk/lurker/message/20090609.213448.b4e4d096.en.html

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/