Messages in this thread | | | Date | Thu, 23 Apr 2009 16:06:52 -0400 | From | Masami Hiramatsu <> | Subject | Re: [PATCH 1/5] ftrace: use module notifier for function tracer |
| |
Anders Kaseorg wrote: > On Wed, 22 Apr 2009, Masami Hiramatsu wrote: >> Could you also add "use text_poke() on x86" to your plan? :-) > > That should be possible now that it is usable inside stop_machine(). It > would be nicer to have an API that isn’t x86-specific, though.
Now, text_poke() become atomic and can be called inside stop_machine(). I agree with that text_poke() is currently implemented only on x86, but adding a generic text_poke() which just do memcpy() is easy.
> Another issue is that Ksplice supports patching rodata as well as text, > and text_poke() does not support changes bigger than PAGE_SIZE. Though > perhaps text_poke() is not the right function for rodata patches anyway.
PAGE_SIZE limitation is not a problem, because you can call text_poke() repeatedly. But indeed, handling rodata in text_poke() is a bit odd...
I assume that you are using alias pages (mapping ro-pages to rw-area) in Ksplice, and if so, I think we can make it as a generic function and share it with text_poke().
>> Hmm, I can't agree that we allow module to modify kernel text... >> Is that possible to separate kernel-text swapping routine from Ksplice >> module? In that case, we don't need to export text_mutex. > > No, it’s not enough for Ksplice to lock the kernel text only while > actively swapping it. We also need to prevent changes to the kernel text > while Ksplice is doing run-pre matching to ensure safety. This means that > Ksplice wants to hold text_mutex for essentially the entire time it’s > running.
Then, why can't you move that "matching" routine into the kernel too? :-)
Thank you,
-- Masami Hiramatsu
Software Engineer Hitachi Computer Products (America) Inc. Software Solutions Division
e-mail: mhiramat@redhat.com
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |