linux-kernel - Re: [PATCH 08/13 v2] ftrace: do not trace init sections

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]

Message-ID: <alpine.DEB.1.10.0810230732100.31839@gandalf.stny.rr.com>
Date:	Thu, 23 Oct 2008 07:36:37 -0400 (EDT)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Jan Kiszka <jan.kiszka@...mens.com>
cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Abhishek Sagar <sagar.abhishek@...il.com>,
	"David S. Miller" <davem@...emloft.net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 08/13 v2] ftrace: do not trace init sections


On Thu, 23 Oct 2008, Jan Kiszka wrote:

> Steven Rostedt wrote:
> > The recordmcount script is now robust enough not to process any sections
> > but the .text section. But the gcc compiler still adds a call to mcount.
> > 
> > Note: The function mcount looks like:
> > 
> >   ENTRY(mcount)
> > 	ret
> >   END(mcount)
> > 
> > Which means the overhead is just a return.
> > 
> > This patch adds notrace to the init sections to not even bother calling
> > mcount (which simply returns).
> 
> Sorry for a potentially dumb question (didn't follow all recent ftrace
> developments), but doesn't this mean that code in such sections is now
> invisible for all tracers, even with dynamic tracing disabled (in which
> case they should cause no problem)? What if you *do* want to have such
> functions in your trace as they may contribute to problem or give other
> useful hints?

Not a dumb question, I've thought about this too.

Well, you can still add tracing into those functions, just the mcount call 
will not be there. I've thought about other ways to handle this. Perhaps 
add it only when DYNAMIC_FTRACE is configured. But that to me is a new 
feature. The patches I'm submitting is to help with performance, bug 
fixes, and sanity checks. So I left out any optional notraces.

e.g. in init.h I could do something like.

#ifdef CONFIG_DYNAMIC_FTRACE
# define init_notrace notrace
#else
# define init_notrace
#endif

And then use the init_notrace throughout the file. If this is considered 
something that is acceptible for adding into 28, I would be happy to 
supply a patch.

-- 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/