[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1606230936350.7257@pobox.suse.cz>
Date: Thu, 23 Jun 2016 09:45:48 +0200 (CEST)
From: Miroslav Benes <mbenes@...e.cz>
To: Josh Poimboeuf <jpoimboe@...hat.com>
cc: Torsten Duwe <duwe@....de>, Jiri Kosina <jkosina@...e.cz>,
matz@...e.de, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Disable non-ABI-compliant optimisations for live
patching
Hi,
On Wed, 22 Jun 2016, Josh Poimboeuf wrote:
> On Wed, Jun 22, 2016 at 04:24:41PM +0200, Torsten Duwe wrote:
> > Live patching, as we use it, deliberately disrupts the fabric of
> > compile units; thus all assumptions a compiler can make about the
> > control flow may be invalid. As an example, it could analyse that a
> > callee does not touch a caller-saved register at all, so why waste
> > memory bandwidth saving it? The register allocations for the live
> > patch replacement function may however be quite different.
But this exact situation should not be possible. Ftrace stub should (and
it does on x86_64) save the caller-saved registers for us. Otherwise we
would have seen problems with kGraft already.
> > Starting with this example, disable all compiler optimisations that
> > do not strictly comply with the established calling conventions.
It think it is too rough and I'd like to avoid it if possible.
> > Signed-off-by: Torsten Duwe <duwe@...e.de>
> > ---
> >
> > Working on the arm64 ftrace-with-regs/livepatch, it struck me that
> > this is a general problem: with live patching, certain optimisations
> > must be switched off for all architectures, the new(?) IPA register
> > allocator in gcc6 is only one example. We should tackle this
> > well before it bites us.
> >
> > Torsten
>
> I think this is a good idea. While we're at it, should we also disable
> some of the other IPA options? These sound especially problematic:
>
> -fipa-sra
> Perform interprocedural scalar replacement of aggregates, removal of
> unused parameters and replacement of parameters passed by reference
> by parameters passed by value.
Yes, this changes ABI. There are generally two different situations we
need to solve in kGraft.
1. A to-be-patched function is isra-optimized, then its caller functions
are patched.
2. As we don't use relocations in kGraft yet we need to call kallsyms on
every unexported function. If such function is isra-optimized it is easier
and safer to put it in the very kGraft patch.
This could surely be avoided if one can prove that the new patching
function is optimized in the same way by gcc.
> -fipa-cp
> Perform interprocedural constant propagation. This optimization
> analyzes the program to determine when values passed to functions are
> constants and then optimizes accordingly. This optimization can
> substantially increase performance if the application has constants
> passed to functions.
This is the same situation as isra, I think.
> -fipa-icf
> Perform Identical Code Folding for functions and read-only variables.
> The optimization reduces code size and may disturb unwind stacks by
> replacing a function by equivalent one with a different name. The
> optimization works more effectively with link time optimization
> enabled.
I haven't met this one yet since we don't have it enabled in SLES as of
now. Could be problem...
Regards,
Miroslav
> >
> > ---
> > Makefile | 7 +++++++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index b409076..424d2e6 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -743,6 +743,13 @@ KBUILD_CFLAGS += $(call cc-option, -femit-struct-debug-baseonly) \
> > $(call cc-option,-fno-var-tracking)
> > endif
> >
> > +ifdef CONFIG_LIVEPATCH
> > +# The compiler might generate ABI "shortcuts" to speed up the code,
> > +# making assumptions which are no longer valid when live patching
> > +# is enabled. Disable all of them.
> > +KBUILD_CFLAGS += $(call cc-option,-fno-ipa-ra)
> > +endif
> > +
> > ifdef CONFIG_FUNCTION_TRACER
> > ifndef CC_FLAGS_FTRACE
> > CC_FLAGS_FTRACE := -pg
> > --
> > 2.6.6
> >
>
> --
> Josh
> --
> To unsubscribe from this list: send the line "unsubscribe live-patching" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Powered by blists - more mailing lists