Live-Patching Archive on lore.kernel.org
 help / color / Atom feed
From: Miroslav Benes <mbenes@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Joe Lawrence <joe.lawrence@redhat.com>,
	Jessica Yu <jeyu@kernel.org>,
	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>,
	mjambor@suse.cz
Subject: Re: [PATCH v3 5/6] x86/ftrace: Use text_poke()
Date: Wed, 22 Jan 2020 16:05:27 +0100 (CET)
Message-ID: <alpine.LSU.2.21.2001221556160.15957@pobox.suse.cz> (raw)
In-Reply-To: <alpine.LSU.2.21.2001221312030.15957@pobox.suse.cz>

On Wed, 22 Jan 2020, Miroslav Benes wrote:

> On Tue, 21 Jan 2020, Josh Poimboeuf wrote:
> 
> > On Tue, Jan 21, 2020 at 09:35:28AM +0100, Miroslav Benes wrote:
> > > On Mon, 20 Jan 2020, Josh Poimboeuf wrote:
> > > 
> > > > 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.
> > > 
> > > Ugh, that is unfortunate. Have you reported it?
> > 
> > Not yet (but I plan to).
> 
> My findings so far...
> 
> I bisected through GCC options which -flive-patching disables and 
> -fno-ipa-pure-const is the culprit. I got no warnings without the option 
> with my config.
> 
> Then I found out allmodconfig was ok even with -flive-patching. 
> CONFIG_GCOV is the difference. CONFIG_GCOV=y seems to make the warnings go 
> away here.

Sorry, that was a red herring. See 867ac9d73709 ("objtool: Fix gcov check 
for older versions of GCC").

I started looking at some btrfs reports and then found out those were 
already fixed. 
https://lore.kernel.org/linux-btrfs/cd4091e4-1c04-a880-f239-00bc053f46a2@infradead.org/

arch/x86/kernel/cpu/mce/core.o: warning: objtool: mce_panic()+0x11b: unreachable instruction
was next...

Broken code (-fno-ipa-pure-const):
...
    1186:       e8 a5 fe ff ff          callq  1030 <wait_for_panic>
    118b:       e9 23 ff ff ff          jmpq   10b3 <mce_panic+0x43>
</end of function>

Working code (-fipa-pure-const):
     753:       e8 88 fe ff ff          callq  5e0 <wait_for_panic>
     758:       0f 1f 84 00 00 00 00    nopl   0x0(%rax,%rax,1)
     75f:       00 

mce_panic() has:
                if (atomic_inc_return(&mce_panicked) > 1)                                                              
                        wait_for_panic();
                barrier();
                
                bust_spinlocks(1);                                                                                     

jmpq in the broken code goes to bust_spinlocks(1), because GCC does not 
know that wait_for_panic() is noreturn... because it is not. 
wait_for_panic() calls panic() unconditionally in the end, which is 
noreturn.

So the question is why ipa-pure-const optimization knows about panic()'s 
noreturn. The answer is that it is right one of the things the 
optimization does. It propagates inner noreturns to its callers. (Martin 
Jambor CCed).

Marking wait_for_panic() as noreturn (__noreturn), of course, fixes it 
then. Now I don't know what the right fix should be. Should we mark all 
these sites as noreturn, or is it ok for the kernel to rely on GCC 
behaviour in this case? Could we teach objtool to recognize this?

Miroslav

  reply index

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20191007081945.10951536.8@infradead.org>
     [not found] ` <20191008104335.6fcd78c9@gandalf.local.home>
     [not found]   ` <20191009224135.2dcf7767@oasis.local.home>
     [not found]     ` <20191010092054.GR2311@hirez.programming.kicks-ass.net>
     [not found]       ` <20191010091956.48fbcf42@gandalf.local.home>
     [not found]         ` <20191010140513.GT2311@hirez.programming.kicks-ass.net>
     [not found]           ` <20191010115449.22044b53@gandalf.local.home>
     [not found]             ` <20191010172819.GS2328@hirez.programming.kicks-ass.net>
     [not found]               ` <20191011125903.GN2359@hirez.programming.kicks-ass.net>
     [not found]                 ` <20191015130739.GA23565@linux-8ccs>
     [not found]                   ` <20191015135634.GK2328@hirez.programming.kicks-ass.net>
2019-10-15 14:13                     ` Miroslav Benes
2019-10-15 15:06                       ` Joe Lawrence
2019-10-15 15:31                         ` Jessica Yu
2019-10-15 22:17                           ` Joe Lawrence
2019-10-15 22:27                             ` Steven Rostedt
2019-10-16  7:42                               ` Peter Zijlstra
2019-10-16 10:15                                 ` Miroslav Benes
2019-10-21 15:05                                 ` Josh Poimboeuf
2020-01-20 16:50                                   ` Josh Poimboeuf
2020-01-21  8:35                                     ` Miroslav Benes
2020-01-21 16:10                                       ` Josh Poimboeuf
2020-01-22 10:09                                         ` Miroslav Benes
2020-01-22 21:42                                           ` Josh Poimboeuf
2020-01-28  9:28                                             ` Miroslav Benes
2020-01-28 15:00                                               ` Josh Poimboeuf
2020-01-28 15:40                                                 ` Petr Mladek
2020-01-28 17:02                                                   ` Josh Poimboeuf
2020-01-29  0:46                                                     ` Jiri Kosina
2020-01-29  2:17                                                       ` Josh Poimboeuf
2020-01-29  3:14                                                         ` Jiri Kosina
2020-01-29 12:28                                                     ` Miroslav Benes
2020-01-29 15:59                                                       ` Josh Poimboeuf
2020-01-30  9:53                                                         ` Petr Mladek
2020-01-30 14:17                                                           ` Josh Poimboeuf
2020-01-31  7:17                                                             ` Petr Mladek
2020-01-22 12:15                                         ` Miroslav Benes
2020-01-22 15:05                                           ` Miroslav Benes [this message]
2020-01-22 22:03                                             ` Josh Poimboeuf
2020-01-23 10:19                                               ` Martin Jambor
2019-10-16  7:49                               ` Peter Zijlstra
2019-10-16 10:20                                 ` Miroslav Benes
2019-10-16 13:29                                   ` Miroslav Benes
2019-10-18 13:03                                     ` Jessica Yu
2019-10-18 13:40                                       ` Petr Mladek
2019-10-21 14:14                                         ` Jessica Yu
2019-10-21 15:31                                         ` Josh Poimboeuf
2019-10-22  8:27                                       ` Miroslav Benes
2019-10-22 14:31                                         ` Josh Poimboeuf
2019-10-23  9:04                                           ` Miroslav Benes
2019-10-16  6:51                         ` Miroslav Benes
2019-10-16  9:23                           ` Peter Zijlstra
2019-10-16  9:36                             ` Jessica Yu
2019-10-16  9:51                               ` Peter Zijlstra
2019-10-16 12:39                           ` Peter Zijlstra
2019-10-22  8:45                             ` Miroslav Benes

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.LSU.2.21.2001221556160.15957@pobox.suse.cz \
    --to=mbenes@suse.cz \
    --cc=ard.biesheuvel@linaro.org \
    --cc=bristot@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jbaron@akamai.com \
    --cc=jeyu@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mjambor@suse.cz \
    --cc=namit@vmware.com \
    --cc=peterz@infradead.org \
    --cc=rdunlap@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Live-Patching Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/live-patching/0 live-patching/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 live-patching live-patching/ https://lore.kernel.org/live-patching \
		live-patching@vger.kernel.org
	public-inbox-index live-patching

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.live-patching


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git