mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Gabriel C <nix.or.die@gmail.com>
Cc: Benjamin Gilbert <bgilbert@redhat.com>,
	linux-x86_64@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
	bero@lindev.ch, Andi Kleen <ak@linux.intel.com>
Subject: Re: 4.17.x won't boot due to "x86/boot/compressed/64: Handle 5-level paging boot if kernel is above 4G"
Date: Tue, 3 Jul 2018 17:21:50 +0300	[thread overview]
Message-ID: <20180703142150.tqckl7miou3wf33q@kshutemo-mobl1> (raw)
In-Reply-To: <20180703124403.veiak4vnbxtmwhv2@kshutemo-mobl1>

On Tue, Jul 03, 2018 at 03:44:03PM +0300, Kirill A. Shutemov wrote:
> On Tue, Jul 03, 2018 at 01:24:49PM +0200, Gabriel C wrote:
> > 2018-07-01 23:32 GMT+02:00 Benjamin Gilbert <bgilbert@redhat.com>:
> > > On Sun, Jul 01, 2018 at 05:15:59PM -0400, Benjamin Gilbert wrote:
> > >> 4.17 kernels built with the CoreOS Container Linux toolchain and kconfig,
> > >> up to and including 4.17.3, fail to boot on AMD64 running in (at least)
> > >> QEMU/KVM.  No messages are shown post-GRUB; the VM instantly reboots.
> > >> Reverting commit 194a9749c73d ("x86/boot/compressed/64: Handle 5-level
> > >> paging boot if kernel is above 4G") fixes it.  I've attached our kernel
> > >> config for reference, and am happy to test patches, provide sample QCOW
> > >> images, etc.
> > >
> > 
> > Also see https://bugzilla.kernel.org/show_bug.cgi?id=200385 ,
> > 
> > 0a1756bd2897951c03c1cb671bdfd40729ac2177 is acting up
> > too with the same symptoms
> 
> I tracked it down to -flto in LDFLAGS. I'll look more into this.

-flto in LDFLAGS screws up this part of paging_prepare():

	/* Copy trampoline code in place */
	memcpy(trampoline_32bit + TRAMPOLINE_32BIT_CODE_OFFSET / sizeof(unsigned long),
			&trampoline_32bit_src, TRAMPOLINE_32BIT_CODE_SIZE);

In particular, relocation for trampoline_32bit_src solved in the wrong
way. Without -flto, we have rip-realtive address load:

  982d30:	48 8d 35 09 cc ff ff 	lea    -0x33f7(%rip),%rsi        # 97f940 <trampoline_32bit_src>

With -flto we have immediate load:

  982cf0:	48 c7 c6 f0 f8 97 00 	mov    $0x97f8f0,%rsi

It only would be okay if bootloader loads kernel at the address we compile
it for. But it's not usually the case.

As result we copy garbage into trampoline and crash when trying to execute
it.

I don't know how to solve it. As far as I know we don't support compiling
kernel with LTO in mainline.

Any suggestions?

Benjamin, do you change LDFLAGS or CFLAGS when compiling the kernel?

-- 
 Kirill A. Shutemov

  parent reply	other threads:[~2018-07-03 14:22 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAF=P+=5c-baQp-CK1ViG8h=mMRv6d3EgEsN_U4rbBx-Pwv_Krw@mail.gmail.com>
2018-07-01 21:32 ` Benjamin Gilbert
2018-07-02  9:34   ` Kirill A. Shutemov
2018-07-02 19:01     ` Benjamin Gilbert
2018-07-03  8:30       ` Kirill A. Shutemov
2018-07-03  8:59         ` Thomas Gleixner
2018-07-03 11:01           ` Kirill A. Shutemov
2018-07-03 11:24   ` Gabriel C
2018-07-03 12:44     ` Kirill A. Shutemov
2018-07-03 14:02       ` Thomas Gleixner
2018-07-03 14:07         ` Bernhard Rosenkraenzer
2018-07-03 14:19           ` Thomas Gleixner
2018-07-03 14:21       ` Kirill A. Shutemov [this message]
2018-07-03 14:27         ` Thomas Gleixner
2018-07-03 18:03         ` Andi Kleen
2018-07-03 20:26           ` Kirill A. Shutemov
2018-07-03 21:00             ` Andi Kleen
2018-07-04  3:10         ` Benjamin Gilbert
2018-07-04 13:21           ` Kirill A. Shutemov
2018-07-04 15:08         ` Kirill A. Shutemov
2018-07-04 20:42           ` Benjamin Gilbert
2018-07-06  6:37           ` Masahiro Yamada
2018-07-06 10:41             ` Kirill A. Shutemov
2018-07-06 14:13               ` Masahiro Yamada
2018-07-06 14:39                 ` Gabriel C
2018-07-06 16:33                   ` Kirill A. Shutemov
2018-07-06 17:31                     ` Gabriel C
2018-07-07  0:55                   ` Masahiro Yamada
2018-07-06 16:29                 ` Kirill A. Shutemov
2018-07-06 18:11                   ` Andi Kleen
2018-07-06 19:34                     ` Benjamin Gilbert
2018-07-07  1:21                   ` Masahiro Yamada
2018-07-09 10:10                     ` Kirill A. Shutemov
2018-07-09 10:37                       ` Masahiro Yamada
2018-07-25 17:26 Dmitry Malkin
2018-07-25 21:21 ` Kirill A. Shutemov
2018-07-26  8:10   ` Dmitry Malkin
2018-07-26 14:50     ` Kirill A. Shutemov
2018-07-26 16:21       ` Dmitry Malkin
2018-07-27 13:46         ` Kirill A. Shutemov

Reply instructions:

You may reply publicly 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=20180703142150.tqckl7miou3wf33q@kshutemo-mobl1 \
    --to=kirill@shutemov.name \
    --cc=ak@linux.intel.com \
    --cc=bero@lindev.ch \
    --cc=bgilbert@redhat.com \
    --cc=hpa@zytor.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-x86_64@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=nix.or.die@gmail.com \
    --cc=tglx@linutronix.de \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®