[lkml]   [2009]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH -tip 0/4] Text edit lock and atomic text_poke()

On Fri, 6 Mar 2009, Mathieu Desnoyers wrote:

> * Masami Hiramatsu ( wrote:
> > Hi,
> >
> > Here is a series of patches which introduce text_mutex for protecting
> > editing kernel text from each other subsystems, and make text_poke()
> > atomic by using fixmap.
> >
> > BTW,
> >
> > > Paravirt and alternatives are always done when SMP is inactive, so there is no
> > > need to use locks.
> >
> > Mathieu, I'm not sure that means. alternatives will be called from module
> > init code and other place where the system has already been running multi-
> > -threads(and they use smp_alt mutex). So, is it possible that those functions
> > will sleep or yield to another process?
> >
> As I remember, module code uses text_poke_early when modifying the
> module text _before_ the module is made available to the rest of the
> kernel. Therefore, it behaves as if it was in a UP system, and that's
> ok, because only one CPU has to touch the text. Therefore, there is no
> need to use text_poke, and therefore no need to take the text mutex.
> Or maybe has it changed ? But I doubt so.

That is correct. Currently ftrace simply does a probe_kernel_write on
module code to convert the calls to mcount into nops. This is done before
the module is available, and does not require stop_machine nor break
points. Since modules are not included in the DEBUG_RODATA there's no need
to play games with the page tables either.

-- Steve

 \ /
  Last update: 2009-03-06 19:15    [W:0.076 / U:6.072 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site