Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 26 Apr 2019 11:55:22 +0200
From:   Jan Hubicka <hubicka@ucw.cz>
To:     Miroslav Benes <mbenes@suse.cz>
Cc:     Josh Poimboeuf <jpoimboe@redhat.com>,
        live-patching@vger.kernel.org,
        Peter Zijlstra <peterz@infradead.org>,
        Mark Rutland <mark.rutland@arm.com>,
        linux-kernel@vger.kernel.org, mliska@suse.cz
Subject: Re: Livepatch vs LTO
Message-ID: <20190426095522.wyymezuqzkdck6fm@kam.mff.cuni.cz>
References: <20190425152628.ogk4woi3omeocwly@treble>
 <alpine.LSU.2.21.1904261054240.27157@pobox.suse.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.LSU.2.21.1904261054240.27157@pobox.suse.cz>
User-Agent: NeoMutt/20170113 (1.7.2)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

> [ adding CCs ]
> 
> On Thu, 25 Apr 2019, Josh Poimboeuf wrote:
> 
> > Hi all,
> > 
> > On IRC, Peter expressed some concern about -flive-patching, specifically
> > that the flag isn't compatible with LTO.
> > 
> > The upstream kernel currently doesn't support LTO, but Android is using
> > it with LLVM:
> > 
> >   https://source.android.com/devices/tech/debug/kcfi
> > 
> > And there seems to be progress being made in that direction for
> > upstream.
> > 
> > Live patching has at least the following issues with LTO:
> > 
> > - For source-based patch generation (klp-convert and friends), the GCC
> >   manual says that -flive-patching is incompatible with LTO.  Does
> >   anybody know if that's a hard incompatibility, or can it be fixed?
> 
> Honza could know more. It was either that LTO by itself complicates 
> things for live patching, or that LTO adds more optimizations which are 
> potentially unsafe.

The original patch, by Oracle, was disabling inlining of everyting else
than static functions and later it was strenghtened to disable all the
other inter-procedural optimization as well. With LTO this does not make
that much of sense because, based on linker resolution file, GCC will
turn non-static functions to static when it knows that non-LTO code will
not bind to it.  To make this work we would need to track what was
static originally and what not. But doing so would still prevent most of
LTO transforms because it is all about cross-module inlining and 
propagation and that all needs to be forbidden for this mode of live
patching to make sense.

So basically -flto -flive-patching=inline-only-static would be pretty
much equivalent of -ffunction-sections -fdata-section and enabling
removal of dead sections in the linker. Just slower at compile time.

The clone tracking logic is more compatible with LTO becuase it does not
prevent most optimizations.  I guess it could work and we probably want
to add support for it incrementally.
> 
> >   Also, what about the performance implications of this flag with LTO?
> >   Might they become more pronounced?
> 
> It could. Theoretically. The scope for optimizations would be much 
> broader.
> 
> >   Also I wonder if -fdump-ipa-clones works with LTO?
> 
> It should. According to Martin, there is (almost) nothing special about 
> LTO. Optimization infrastructure is the same, only the scope is not 
> limited to one translation unit.

Yes, you will likely get considerably more clones and inline copies to
care about while doing the live patch.  I would be interested to know
how well it work in practice. No idea if that would be a problem.

Honza