[lkml]   [2015]   [Mar]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subject[PATCH v2 0/2] livepatch/module: Avoid races between modules and live patches
There is a notifier that handles live patches for coming and going modules.
It takes klp_mutex lock to avoid races with coming and going patches.

Unfortunately, there are some possible races in the current implementation.
The problem is that we do not keep the klp_mutex lock all the time when
the module is being added or removed.

All the problems should get fixed by the two patches.

Some of the problems will be visible only after we add a more complex
consistency model and start supporting semantics changes in patched
functions. But I would like to fix it already now. We will need it
anyway. IMHO, the current solution is more elegant than any temporary
hacks. The patchset with consistency model will be complex enough.
Let's solve some problems even before.

Thanks a lot Josh for pointing out that module_ftrace_init() is called
in MODULE_STALE_UNFORMED. It inspired me for the other solution
of coming modules.

Changes in v2:

+ split fix for coming and going modules
+ call klp_module_init() directly instead of using a handler
+ check if mod is not NULL when checking the module state
+ use the boolean flag only for going handler

Petr Mladek (2):
livepatch/module: Apply patch when loaded module is unformed
livepatch/module: Correctly handle going modules

include/linux/livepatch.h | 10 ++++
include/linux/module.h | 4 ++
kernel/livepatch/core.c | 124 +++++++++++++++++++++++++++++++++++-----------
kernel/module.c | 9 ++++
4 files changed, 119 insertions(+), 28 deletions(-)


 \ /
  Last update: 2015-03-05 17:01    [W:0.129 / U:0.692 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site