LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Christoffer Dall <christofferdall@christofferdall.dk>
Cc: Marc Zyngier <marc.zyngier@arm.com>,
	Russell King <rmk@arm.linux.org.uk>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	KVM General <kvm@vger.kernel.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: randconfig bug: ARM/KVM link error in hyp_idmap section
Date: Thu, 29 Jan 2015 16:53:01 +0100	[thread overview]
Message-ID: <1611315.VFEsrxkfBf@wuerfel> (raw)
In-Reply-To: <CAEDV+gJ3YO8oeka_yaJGg+LXA0Od0TGkZb8vD_q74xNRx9g0Rg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2728 bytes --]

On Thursday 29 January 2015 16:23:42 Christoffer Dall wrote:
> On Wed, Jan 28, 2015 at 8:57 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>
> > 8<----
> > Subject: [PATCH] ARM: KVM: avoid "HYP init code too big" error
> >
> > When building large kernels, the linker will emit lots of veneers
> > into the .hyp.idmap.text section, which causes it to grow beyond
> > one page, and that triggers the build error.
> >
> 
> do you have a config handy that generates this error?

Attached to this mail. Use on linux-next

> > This moves the section into .rodata instead, which avoids the
> > veneers and is safe because the code is not executed directly
> > but always copied into a separate page first.
> >
> > I am unsure if I wrote this the correct way though, so
> > it needs to be reviewed carefully.
> >
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> >
> > diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> > index ce01a2d3339f..f4de6e16d951 100644
> > --- a/arch/arm/kernel/vmlinux.lds.S
> > +++ b/arch/arm/kernel/vmlinux.lds.S
> > @@ -23,10 +23,14 @@
> >         VMLINUX_SYMBOL(__idmap_text_start) = .;                         \
> >         *(.idmap.text)                                                  \
> >         VMLINUX_SYMBOL(__idmap_text_end) = .;                           \
> > -       . = ALIGN(32);                                                  \
> > +       . = ALIGN(32);
> > +
> > +#define IDMAP_RODATA                                                   \
> > +       .rodata : {                                                     \
> >         VMLINUX_SYMBOL(__hyp_idmap_text_start) = .;                     \
> >         *(.hyp.idmap.text)                                              \
> > -       VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
> > +       VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;                       \
> > +       }
> >
> >  #ifdef CONFIG_HOTPLUG_CPU
> >  #define ARM_CPU_DISCARD(x)
> > @@ -123,6 +127,7 @@ SECTIONS
> >         . = ALIGN(1<<SECTION_SHIFT);
> >  #endif
> >         RO_DATA(PAGE_SIZE)
> > +       IDMAP_RODATA
> >
> >         . = ALIGN(4);
> >         __ex_table : AT(ADDR(__ex_table) - LOAD_OFFSET) {
> >
> >
> the changes look ok, but I don't understand why putting stuff in rodata is
> a good solution, is it simply by chance that the linker then generates
> fewer veneers there?  I think we're only branching internally in the hyp
> idmap text page anyhow, so wondering why this appears in the first place...
> hmmm.

The linker will not generate any veneers for .rodata because it does not
expect executable code in there. As I said, above, this is also correct
because it matches how we access that section (read-only, never execute).

	Arnd

[-- Attachment #2: 0x203B430A-config.gz --]
[-- Type: application/gzip, Size: 26652 bytes --]

  parent reply	other threads:[~2015-01-29 15:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-28 19:57 Arnd Bergmann
     [not found] ` <CAEDV+gJ3YO8oeka_yaJGg+LXA0Od0TGkZb8vD_q74xNRx9g0Rg@mail.gmail.com>
2015-01-29 15:53   ` Arnd Bergmann [this message]
2015-01-29 16:01     ` Marc Zyngier
     [not found]       ` <CAEDV+gKzkER4n=oNiM1wNmNnbMEosYKo=Awu8j8R5Fr7kzE_Ew@mail.gmail.com>
2015-01-29 17:51         ` Marc Zyngier

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=1611315.VFEsrxkfBf@wuerfel \
    --to=arnd@arndb.de \
    --cc=christofferdall@christofferdall.dk \
    --cc=kvm@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=rmk@arm.linux.org.uk \
    --subject='Re: randconfig bug: ARM/KVM link error in hyp_idmap section' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).