[lkml]   [2019]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v15 05/11] livepatch: Simplify API by removing registration step
On Wed, 9 Jan 2019, Petr Mladek wrote:

> The possibility to re-enable a registered patch was useful for immediate
> patches where the livepatch module had to stay until the system reboot.
> The improved consistency model allows to achieve the same result by
> unloading and loading the livepatch module again.
> Also we are going to add a feature called atomic replace. It will allow
> to create a patch that would replace all already registered patches.
> The aim is to handle dependent patches more securely. It will obsolete
> the stack of patches that helped to handle the dependencies so far.
> Then it might be unclear when a cumulative patch re-enabling is safe.
> It would be complicated to support the many modes. Instead we could
> actually make the API and code easier to understand.
> Therefore, remove the two step public API. All the checks and init calls
> are moved from klp_register_patch() to klp_enabled_patch(). Also the patch
> is automatically freed, including the sysfs interface when the transition
> to the disabled state is completed.
> As a result, there is never a disabled patch on the top of the stack.
> Therefore we do not need to check the stack in __klp_enable_patch().
> And we could simplify the check in __klp_disable_patch().
> Also the API and logic is much easier. It is enough to call
> klp_enable_patch() in module_init() call. The patch can be disabled
> by writing '0' into /sys/kernel/livepatch/<patch>/enabled. Then the module
> can be removed once the transition finishes and sysfs interface is freed.
> The only problem is how to free the structures and kobjects safely.
> The operation is triggered from the sysfs interface. We could not put
> the related kobject from there because it would cause lock inversion
> between klp_mutex and kernfs locks, see kn->count lockdep map.
> Therefore, offload the free task to a workqueue. It is perfectly fine:
> + The patch can no longer be used in the livepatch operations.
> + The module could not be removed until the free operation finishes
> and module_put() is called.
> + The operation is asynchronous already when the first
> klp_try_complete_transition() fails and another call
> is queued with a delay.
> Suggested-by: Josh Poimboeuf <>
> Signed-off-by: Petr Mladek <>

Acked-by: Miroslav Benes <>


 \ /
  Last update: 2019-01-10 13:33    [W:0.080 / U:0.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site