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:   Mon, 20 Jan 2020 10:50:39 -0600
From:   Josh Poimboeuf <jpoimboe@redhat.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Steven Rostedt <rostedt@goodmis.org>,
        Joe Lawrence <joe.lawrence@redhat.com>,
        Jessica Yu <jeyu@kernel.org>, Miroslav Benes <mbenes@suse.cz>,
        x86@kernel.org, linux-kernel@vger.kernel.org, mhiramat@kernel.org,
        bristot@redhat.com, jbaron@akamai.com,
        torvalds@linux-foundation.org, tglx@linutronix.de,
        mingo@kernel.org, namit@vmware.com, hpa@zytor.com, luto@kernel.org,
        ard.biesheuvel@linaro.org, live-patching@vger.kernel.org,
        Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()
Message-ID: <20200120165039.6hohicj5o52gdghu@treble>
References: <20191011125903.GN2359@hirez.programming.kicks-ass.net>
 <20191015130739.GA23565@linux-8ccs>
 <20191015135634.GK2328@hirez.programming.kicks-ass.net>
 <alpine.LSU.2.21.1910151611000.13169@pobox.suse.cz>
 <88bab814-ea24-ece9-2bc0-7a1e10a62f12@redhat.com>
 <20191015153120.GA21580@linux-8ccs>
 <7e9c7dd1-809e-f130-26a3-3d3328477437@redhat.com>
 <20191015182705.1aeec284@gandalf.local.home>
 <20191016074217.GL2328@hirez.programming.kicks-ass.net>
 <20191021150549.bitgqifqk2tbd3aj@treble>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20191021150549.bitgqifqk2tbd3aj@treble>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Oct 21, 2019 at 10:05:49AM -0500, Josh Poimboeuf wrote:
> On Wed, Oct 16, 2019 at 09:42:17AM +0200, Peter Zijlstra wrote:
> > > which are not compatible with livepatching. GCC upstream now has
> > > -flive-patching option, which disables all those interfering optimizations.
> > 
> > Which, IIRC, has a significant performance impact and should thus really
> > not be used...
> > 
> > If distros ship that crap, I'm going to laugh at them the next time they
> > want a single digit performance improvement because *important*.
> 
> I have a crazy plan to try to use objtool to detect function changes at
> a binary level, which would hopefully allow us to drop this flag.
> 
> But regardless, I wonder if we enabled this flag prematurely.  We still
> don't have a reasonable way to use it for creating source-based live
> patches upstream, and it should really be optional for CONFIG_LIVEPATCH,
> since kpatch-build doesn't need it.

I also just discovered that -flive-patching is responsible for all those
"unreachable instruction" objtool warnings which Randy has been
dutifully bugging me about over the last several months.  For some
reason it subtly breaks GCC implicit noreturn detection for local
functions.

At this point, I only see downsides of -flive-patching, at least until
we actually have real upstream code which needs it.

If there aren't any objections I'll be posting a patch soon to revert.

-- 
Josh