[lkml]   [2019]   [Feb]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] livepatch: Enforce reliable stack trace as config dependency
On Sat, Feb 09, 2019 at 02:47:28PM +0530, Kamalesh Babulal wrote:
> While the consistency model was introduced, architectures without the
> reliable stack trace implementation could use the immediate flag for
> livepatching but with its own limitations.
> After removal of the immediate flag by commit d0807da78e11
> ("livepatch: Remove immediate feature"), reliable stack trace became
> enforcing dependency for livepatch support on any architecture. In
> the current code, we ensure that the dependency is met when
> enabling the patch during the module load.
> This dependency check can be improved by moving it to the Kconfig,
> which disables the support for livepatching in the kernel for unmet
> dependencies. This patch moves both HAVE_RELIABLE_STACKTRACE and
> STACKTRACE under config LIVEPATCH, it also removes the
> klp_have_reliable_stack() function.
> Loading a livepatching module on an architecture where reliable
> stack trace is yet to be implemented, the user should see:
> insmod: ERROR: could not insert module ./livepatch-sample.ko: Invalid module format
> ...
> [ 286.453463] livepatch_sample: module is marked as livepatch module, but livepatch support is disabled

Wouldn't the module fail to build in the first place, since

Anyway, I'm not sure about this approach. This patch makes the s390
livepatch code no longer compilable, turning it into completely dead
code. So if something changes in the s390 code which causes it to stop
compiling, nobody will notice.

I think I'd rather go in the opposite direction: allow the patches to be
loaded. Then they can be forced, if needed. That enables both compile
and runtime testing. That way we don't make any backward progress,
until such arches get reliable stacktraces.


 \ /
  Last update: 2019-02-11 15:09    [W:0.033 / U:1.248 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site