linux-kernel - Re: [PATCH 0/5] ftrace: to kill a daemon

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: <863e9df20808090248h3adc2ac3mdb3217fe2876ab3b@mail.gmail.com>
Date:	Sat, 9 Aug 2008 15:18:14 +0530
From:	"Abhishek Sagar" <sagar.abhishek@...il.com>
To:	"Steven Rostedt" <rostedt@...dmis.org>
Cc:	linux-kernel@...r.kernel.org, "Ingo Molnar" <mingo@...e.hu>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Peter Zijlstra" <peterz@...radead.org>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"David Miller" <davem@...emloft.net>,
	"Mathieu Desnoyers" <mathieu.desnoyers@...ymtl.ca>,
	"Roland McGrath" <roland@...hat.com>,
	"Ulrich Drepper" <drepper@...hat.com>,
	"Rusty Russell" <rusty@...tcorp.com.au>,
	"Jeremy Fitzhardinge" <jeremy@...p.org>,
	"Gregory Haskins" <ghaskins@...ell.com>,
	"Arnaldo Carvalho de Melo" <acme@...hat.com>,
	"Luis Claudio R. Goncalves" <lclaudio@...g.org>,
	"Clark Williams" <williams@...hat.com>
Subject: Re: [PATCH 0/5] ftrace: to kill a daemon

On Thu, Aug 7, 2008 at 11:50 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> You see, the reason for this is that for ftrace to maintain performance
> when configured in but disabled, it would need to change all the
> locations that called "mcount" (enabled with the gcc -pg option) into
> nops.  The "-pg" option in gcc sets up a function profiler to call this
> function called "mcount". If you simply have "mcount" return, it will
> still add 15 to 18% overhead in performance. Changing all the calls to
> nops moved the overhead into noise.
>
> To get rid of this, I had the mcount code record the location that called
> it. Later, the "ftraced" daemon would wake up and look to see if
> any new functions were recorded. If so, it would call kstop_machine
> and convert the calls to "nops". We needed kstop_machine because bad
> things happen on SMP if you modify code that happens to be in the
> instruction cache of another CPU.

Is this new framework needed for x86 specific reasons only? From what
I gathered here, ftraced defers mcount patching simply because there's
no way to update a 5-byte nop atomically. If so, why can't mcount site
patching be left to arch specific ftrace code? For !SMP or archs which
generate word sized mcount branch calls (e.g, ARM) is there really no
way to patch  mcount sites synchronously from inside ftrace_record_ip
by disabling interrupts?

Regards,
Abhishek Sagar
--
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/