Re: [PATCH 1/5] ftrace: use module notifier for function tracer

From: Tim Abbott
Date: Thu Apr 23 2009 - 18:33:10 EST


On Thu, 23 Apr 2009, Mathieu Desnoyers wrote:
> how about a kernel Ksplice API which lets your patch modules get
> their handlers executed under the right execution context ? E.g. :
[...]
> This way, the kernel code-base would contain the tricky locking bits.
> It seems much better than exporting the text_mutex to modules.

On Thu, 23 Apr 2009, Masami Hiramatsu wrote:
> Then, why can't you move that "matching" routine into the kernel too? :-)

I think both of you are assuming that Ksplice is grabbing text_mutex in
the patch modules for each update, which isn't what's going on. There are
two types of modules associated with Ksplice, the per-update patch modules
and the Ksplice core, which could be built as a module.

The patch modules for each update are already stub modules that just load
some data into a data structure and call into the Ksplice core at
module_init/cleanup (by Ksplice core, I mean kernel/ksplice.c). All the
tricky bits including the run-pre matching routine and the locking code
are in the Ksplice core.

The reason that we want to export text_mutex is that it can be useful for
the Ksplice core (still kernel/ksplice.c) to be built as a module. This
is desirable when a different version of the kernel/ksplice.c code is
needed in order to apply a particular update (e.g. because there was a bug
in Ksplice).


I agree that great care should be taken when writing code that patches the
kernel's text. However, I don't think failing to export text_mutex to GPL
modules helps ensure that. In particular, not exporting text_mutex
doesn't prevent modules from patching the kernel text. It just prevents
any modules that do so from grabbing the appropriate lock.

-Tim Abbott


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/