linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v2 0/2] Fix ordering of ftrace/livepatch calls on module load and unload
@ 2016-02-02  1:17 Jessica Yu
  2016-02-02  1:17 ` [PATCH v2 1/2] ftrace/module: remove ftrace module notifier Jessica Yu
                   ` (2 more replies)
  0 siblings, 3 replies; 23+ messages in thread
From: Jessica Yu @ 2016-02-02  1:17 UTC (permalink / raw)
  To: Josh Poimboeuf, Seth Jennings, Jiri Kosina, Vojtech Pavlik,
	Miroslav Benes, Rusty Russell, Steven Rostedt, Ingo Molnar
  Cc: live-patching, linux-kernel, Jessica Yu

As explained here [1], livepatch modules are failing to initialize properly
because the ftrace coming module notifier (which calls
ftrace_module_enable()) runs *after* the livepatch module notifier (which
enables the patch(es)). Thus livepatch attempts to apply patches to
modules before ftrace_module_enable() is even called for the corresponding
module(s). As a result, patch modules break. Ftrace code must run before
livepatch on module load, and the reverse is true on module unload.

For ftrace and livepatch, order of initialization (plus exit/cleanup code)
is important for loading and unloading modules, and using module notifiers
to perform this work is not ideal since it is not always clear what gets
called when. In this patchset, dependence on the module notifier call chain
is removed in favor of hard coding the corresponding function calls in the
module loader. This promotes better code visibility and ensures that ftrace
and livepatch code get called in the correct order on patch module load and
unload.

Tested the changes with a test livepatch module that patches 9p and nilfs2,
and verified that the issue described in [1] is fixed.

Patches are based on linux-next.

v1 can be found here -
http://lkml.kernel.org/g/1454049827-3726-1-git-send-email-jeyu@redhat.com

v2:
- Instead of splitting the ftrace and livepatch notifiers into coming + going
  notifiers and adjusting their priorities, remove ftrace and livepatch notifiers
  completely and hard-code the necessary function calls in the module loader.

[1] http://lkml.kernel.org/g/20160128204033.GA32131@packer-debian-8-amd64.digitalocean.com


Jessica Yu (2):
  ftrace/module: remove ftrace module notifier
  livepatch/module: remove livepatch module notifier

 include/linux/ftrace.h    |   6 +-
 include/linux/livepatch.h |   9 +++
 kernel/livepatch/core.c   | 144 ++++++++++++++++++++++------------------------
 kernel/module.c           |  12 ++++
 kernel/trace/ftrace.c     |  36 +-----------
 5 files changed, 95 insertions(+), 112 deletions(-)

-- 
2.4.3

^ permalink raw reply	[flat|nested] 23+ messages in thread
* [PATCH v2 0/2] Livepatch module notifier cleanup
@ 2016-03-11 20:03 Jessica Yu
  2016-03-11 20:03 ` [PATCH v2 2/2] livepatch/module: remove livepatch module notifier Jessica Yu
  0 siblings, 1 reply; 23+ messages in thread
From: Jessica Yu @ 2016-03-11 20:03 UTC (permalink / raw)
  To: Josh Poimboeuf, Seth Jennings, Jiri Kosina, Vojtech Pavlik,
	Miroslav Benes, Petr Mladek, Rusty Russell
  Cc: Steven Rostedt, live-patching, linux-kernel, Jessica Yu

These are the remaining 2 patches that came from the original ftrace/livepatch
module notifier patchset found here: https://lkml.org/lkml/2016/2/8/1180

Basically, the patchset does a bit of module.c cleanup (patch 1) in
preparation for the klp_module_{coming,going} calls (patch 2). We decided
to stop relying on the module notifier callchain in favor of hard-coding
the appropriate livepatch function calls that handle coming and going
modules. Hard-coding these calls will guarantee that ftrace and livepatch
exit/initialization routines are called in the correct order without
relying on module notifiers.

The patches should be nearly exactly the same as those from the previous
discussion, except in patch 2 I've added back the #if IS_ENABLED(CONFIG_LIVEPATCH)
guard in livepatch.h.

Patches based on linux-next.

Previous discussion (v4) found here: https://lkml.org/lkml/2016/2/8/1180

v2:
  - we don't need to change mod->state to GOING when cleaning up during
    failed module load
  - modify mod->state check to allow klp_module_going() to be called in
    both COMING and GOING states

Jessica Yu (2):
  modules: split part of complete_formation() into prepare_coming_module()
  livepatch/module: remove livepatch module notifier

 include/linux/livepatch.h |  13 ++++
 kernel/livepatch/core.c   | 147 ++++++++++++++++++++++------------------------
 kernel/module.c           |  36 +++++++++---
 3 files changed, 112 insertions(+), 84 deletions(-)

-- 
2.4.3

^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2016-03-14 20:01 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-02  1:17 [PATCH v2 0/2] Fix ordering of ftrace/livepatch calls on module load and unload Jessica Yu
2016-02-02  1:17 ` [PATCH v2 1/2] ftrace/module: remove ftrace module notifier Jessica Yu
2016-02-04 13:27   ` Petr Mladek
2016-02-04 14:18     ` Steven Rostedt
2016-02-04 15:21       ` Petr Mladek
2016-02-04 15:33         ` Steven Rostedt
2016-02-02  1:17 ` [PATCH v2 2/2] livepatch/module: remove livepatch " Jessica Yu
2016-02-04 14:39   ` Petr Mladek
2016-02-04 14:56     ` Steven Rostedt
2016-02-04 16:47     ` Miroslav Benes
2016-02-05  4:11     ` Jessica Yu
2016-02-05  9:15       ` Miroslav Benes
2016-02-05 10:06         ` Petr Mladek
2016-02-08  0:34       ` Rusty Russell
2016-02-04 17:29   ` [PATCH v2 2/2] " Miroslav Benes
2016-02-04 20:55   ` Josh Poimboeuf
2016-02-05  8:59     ` Miroslav Benes
2016-02-04 10:43 ` [PATCH v2 0/2] Fix ordering of ftrace/livepatch calls on module load and unload Jiri Kosina
2016-02-04 13:29   ` Steven Rostedt
2016-02-05  1:17     ` Rusty Russell
2016-03-11 20:03 [PATCH v2 0/2] Livepatch module notifier cleanup Jessica Yu
2016-03-11 20:03 ` [PATCH v2 2/2] livepatch/module: remove livepatch module notifier Jessica Yu
2016-03-14 15:06   ` Petr Mladek
2016-03-14 20:01   ` Josh Poimboeuf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).