[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 8 Aug 2008 08:51:34 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Rusty Russell <rusty@...tcorp.com.au>
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>,
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>,
Steven Rostedt <srostedt@...hat.com>
Subject: Re: [PATCH 3/5] ftrace: enable mcount recording for modules
On Fri, 8 Aug 2008, Rusty Russell wrote:
> On Friday 08 August 2008 04:20:16 Steven Rostedt wrote:
> > This patch enables the loading of the __mcount_section of modules and
> > changing all the callers of mcount into nops.
> >
> > The modification is done before the init_module function is called, so
> > again, we do not need to use kstop_machine to make these changes.
>
> Importantly, before parameter parsing too (which can use module functions
> before the module's init()).
It happens before "module_finalize", so I'm guessing it is also before
parameter passing.
Even if we did it after parameter passing, as long as the code does not
run on another CPU we are fine. Unless the module is setting up interrupt
handlers or kicking off kernel threads, doing the change after parameter
passing would not hurt.
But it looks like we are doing it before that anyway, so it is not an
issue.
Thanks,
-- 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/
Powered by blists - more mailing lists