lkml.org 
[lkml]   [2020]   [Jan]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 5/6] x86/ftrace: Use text_poke()

> > > At this point, I only see downsides of -flive-patching, at least until
> > > we actually have real upstream code which needs it.
> >
> > Can you explain this? The option makes GCC to avoid optimizations which
> > are difficult to detect and would make live patching unsafe. I consider it
> > useful as it is, so if you shared the other downsides and what you meant
> > by real upstream code, we could discuss it.
>
> Only SLES needs it right? Why inflict it on other livepatch users? By
> "real upstream code" I mean there's no (documented) way to create live
> patches using the method which relies on this flag. So I don't see any
> upstream benefits for having it enabled.

I'd put it differently. SLES and upstream need it, RHEL does not need it.
Or anyone using kpatch-build. It is perfectly fine to prepare live patches
just from the source code using upstream live patching infrastructure.
After all, SLES is nothing else than upstream here. We were creating live
patches manually for quite a long time and only recently we have been
using Nicolai's klp-ccp automation (https://github.com/SUSE/klp-ccp).

So, everyone using upstream directly relies on the flag, which seems to be
a clear benefit to me. Reverting the patch would be a step back.

Also I think we're moving in the right direction to make the life of
upstream user easier with a proposal of klp-ccp and Petr's patch set to
split live patch modules. It is a path from inconvenient to comfortable
and not from impossible to possible.

Miroslav

\
 
 \ /
  Last update: 2020-01-22 11:10    [W:0.118 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site